Allow devirt into abstract classes if we saw a non-abstract child by MichalStrehovsky · Pull Request #108379 · dotnet/runtime

@MichalStrehovsky

We avoid devirtualizing into abstract classes because whole program view might have optimized away the method bodies and devirtualizing them doesn't lead to anything good.

However, if the whole program view had a non-abstract child of this, we can no longer optimize this out and devirtualization should be fine.

Fixes issue encountered in dotnet#108153 (comment)

@MichalStrehovsky

MichalStrehovsky added a commit to MichalStrehovsky/runtime that referenced this pull request

Oct 1, 2024
This code was trying to answer question: "Was this method overriden by something else in a more derived class"? It was walking the base hierarchy in canonical form, but that was leading to methods not resolving at all. The fix is to walk the non-canonical hierarchy and canonicalize after we resolved everything.

I ran into this in dotnet#108379 that unlocked more whole program devirtualization and `StringSearchValuesBase` is in this shape.

MichalStrehovsky added a commit that referenced this pull request

Oct 1, 2024
This code was trying to answer question: "Was this method overriden by something else in a more derived class"? It was walking the base hierarchy in canonical form, but that was leading to methods not resolving at all. The fix is to walk the non-canonical hierarchy and canonicalize after we resolved everything.

I ran into this in #108379 that unlocked more whole program devirtualization and `StringSearchValuesBase` is in this shape.

@MichalStrehovsky

MichalStrehovsky added a commit to MichalStrehovsky/runtime that referenced this pull request

Oct 2, 2024
This code was trying to answer question: "Was this method overriden by something else in a more derived class"? It was walking the base hierarchy in canonical form, but that was leading to methods not resolving at all. The fix is to walk the non-canonical hierarchy and canonicalize after we resolved everything.

I ran into this in dotnet#108379 that unlocked more whole program devirtualization and `StringSearchValuesBase` is in this shape.

@MichalStrehovsky

This was referenced

Oct 2, 2024

@MichalStrehovsky

sirntar pushed a commit to sirntar/runtime that referenced this pull request

Oct 3, 2024
This code was trying to answer question: "Was this method overriden by something else in a more derived class"? It was walking the base hierarchy in canonical form, but that was leading to methods not resolving at all. The fix is to walk the non-canonical hierarchy and canonicalize after we resolved everything.

I ran into this in dotnet#108379 that unlocked more whole program devirtualization and `StringSearchValuesBase` is in this shape.

sirntar pushed a commit to sirntar/runtime that referenced this pull request

Oct 3, 2024
…tnet#108379)

We avoid devirtualizing into abstract classes because whole program view might have optimized away the method bodies and devirtualizing them doesn't lead to anything good.

However, if the whole program view had a non-abstract child of this, we can no longer optimize this out and devirtualization should be fine.

Fixes issue encountered in dotnet#108153 (comment)

jeffschwMSFT added a commit that referenced this pull request

Oct 3, 2024
…108470)

This code was trying to answer question: "Was this method overriden by something else in a more derived class"? It was walking the base hierarchy in canonical form, but that was leading to methods not resolving at all. The fix is to walk the non-canonical hierarchy and canonicalize after we resolved everything.

I ran into this in #108379 that unlocked more whole program devirtualization and `StringSearchValuesBase` is in this shape.

Co-authored-by: Jeff Schwartz <jeffschw@microsoft.com>

lambdageek pushed a commit to lambdageek/runtime that referenced this pull request

Oct 3, 2024
This code was trying to answer question: "Was this method overriden by something else in a more derived class"? It was walking the base hierarchy in canonical form, but that was leading to methods not resolving at all. The fix is to walk the non-canonical hierarchy and canonicalize after we resolved everything.

I ran into this in dotnet#108379 that unlocked more whole program devirtualization and `StringSearchValuesBase` is in this shape.

lambdageek pushed a commit to lambdageek/runtime that referenced this pull request

Oct 3, 2024
…tnet#108379)

We avoid devirtualizing into abstract classes because whole program view might have optimized away the method bodies and devirtualizing them doesn't lead to anything good.

However, if the whole program view had a non-abstract child of this, we can no longer optimize this out and devirtualization should be fine.

Fixes issue encountered in dotnet#108153 (comment)