-
Notifications
You must be signed in to change notification settings - Fork 4.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support for devirtualizing array interface methods #62497
Conversation
Update jit and runtime to devirtualize interface calls on arrays. This resolves the first two issues noted in dotnet#62457.
Tagging subscribers to this area: @JulieLeeMSFT Issue DetailsUpdate jit and runtime to devirtualize interface calls on arrays.
|
cc @dotnet/jit-contrib @jkotas @jkotas I imagine there might be some gotcha here. The type punning done by Diffs (via pmi) show a few hits. PGO should see more. The diffs are a bit misleading because until some of these methods are called the jit will first see a no-inline wrapper stub.
|
Sample diff from runtime/src/libraries/System.Linq.Expressions/src/System/Linq/Expressions/LambdaExpression.cs Lines 1115 to 1121 in 09cd9c2
The call to ;; Assembly listing for method Expression:GetDelegateType(ref):Type
;; before
mov rcx, rsi
mov r11, 0xD1FFAB1E
call [r11]ICollection`1:get_Count():int:this
test eax, eax
;; after
mov rcx, rsi
call SZArrayHelper:get_Count():int:this // nominally this should inline (see note above) |
Agree. Looks like that there are failing tests. The implementation of generic array interfaces was always a bug farm. |
Issue seems to be here: Lines 235 to 244 in 02f70d0
The jit devirtualizes the empty array case and (best guess) somehow we don't properly initialize the static
Possibly two issues?
If we can fix the first, I can either have the jit bail out on these cases, or see if I can find the right type to pass somehow. |
Call stack is
and the method table in native frame 3 is
|
I think it means that the devirtualization is stripping the instantiating stub, and you are using virtual method desc signature to call the devirtualized method desc. I think the devirtualization has to avoid stripping the instantiating stub. The instantiating stub is needed to compute the value of the inst param. Or you can bail out in situations where shared generics are involved. I think you will need to bail out for shared generic callsites anyway for the same reason we are bailing out on inlining of shared generic code (we do not have a way to represent these cases on the VM side). |
Going to close this for now -- hope to get back to it once OSR is done. |
Update jit and runtime to devirtualize interface calls on arrays.
This resolves the first two issues noted in #62457.