JIT: enable GDV when static class deduction fails.

[AndyAyersMS]

Update the early bailout in impDevirtualizeCall that gives up if
the object class cannot not be determined to check if we can do
GDV (guarded devirtualization) based on profile data.

Fixes one of the cases noted in #55079.

[AndyAyersMS]

@EgorBo PTAL
cc @dotnet/jit-contrib

On the second test case from #55079:

complus_jitprintdevirtualizedmethods=*
complus_noguionassert=0
complus_tieredpgo=1

corerun.exe ex.exe
Devirtualized virtual call to AFactory:GetA; now direct call to BFactory:GetA [exact]
Devirtualized virtual call to A:GetValue; now direct call to B:GetValue [exact]

and in the jitdump:

impDevirtualizeCall: no type available (op=LCL_VAR)
Considering guarded devirtualization at IL offset 35 (0x23)
Likely class for 0000000000000000 (unknown) is 00007FF93A546AC0 (B) [likelihood:100 classes seen:1]
virtual call would invoke method GetValue
Marking call [000019] as guarded devirtualization candidate; will guess for class B
...
lvaGrabTemp returning 10 (V10 tmp8) (a long lifetime temp) called for guarded devirt this exact temp.

lvaSetClass: setting class for V10 to (00007FF93A546AC0) B  [exact]
Direct call [000086] in block BB11

impDevirtualizeCall: Trying to devirtualize virtual call:
    class for 'this' is B [exact] (attrib 20000000)
    base method is A::GetValue
    devirt to B::GetValue -- exact
               [000086] I-C-G-------              *  CALLV vt-ind int    A.GetValue
               [000088] ------------ this in rcx  \--*  LCL_VAR   ref    V10 tmp8         
    exact; can devirtualize
... after devirt...
               [000086] I-C-G-------              *  CALL nullcheck int    B.GetValue
               [000088] ------------ this in rcx  \--*  LCL_VAR   ref    V10 tmp8         
Devirtualized virtual call to A:GetValue; now direct call to B:GetValue [exact]

[AndyAyersMS]

SPMI only sees one method with a diff.

         137 ( 8.00% of base) : 297269.dasm - System.Net.NTAuthentication:GetOutgoingBlob(System.Byte[],bool,byref):System.Byte[]:this

There were quite a few replay failures (not surprising) so the actual set of diffs is perhaps considerably larger. Not sure how to assess this without merging this and getting a new collection, then undoing this.

For the asp.net collection (~45K methods) there were ~1900 replay failures. Not currently easy to verify these are all caused by the above, but seems plausible.

[AndyAyersMS]

PMI diffs didn't spot anything either, but both diff and base jits failed in SPC where we probably have the most relevant PGO data.

At any rate I think this change is clearly improved functionality and am not too worried about bad diffs.

[EgorBo]

Nice! I actually also tried to fix that via "get class handle for method" but didn't finish it

[AndyAyersMS]

@EgorBo you might try running this over TE, I think your scripting is better than mine.

[EgorBo]

@EgorBo you might try running this over TE, I think your scripting is better than mine.

Sure, I've just started a couple of benchmarks to compare

[AndyAyersMS]

Not obvious how/if the installer test failure (Breadcrumb_thread_does_not_finish_when_app_has_unhandled_exception) is related. Suspect it isn't...

[AndyAyersMS]

Pretty sure failures are unrelated, have kicked off retries but CI doesn't seem to responding. Will look again in the morning.