Set IL offsets for calls created during devirtualization #61189
Conversation
Since inlined statements use the IL location of the inliner's statement all statements created while inlining devirtualized calls would get no debug info before, while normally these will have IL location pointing to the call statement in the root.
dotnet-issue-labeler
bot
added
the
area-CodeGen-coreclr
|
Tagging subscribers to this area: @JulieLeeMSFT Issue DetailsSince inlined statements use the IL location of the inliner's statement This behavior seems unwanted and was hard to keep with my upcoming debug info changes since there we are always able to walk back to the root context and get the IL offset from there, and it is hard to check for this particular case (call statement in an inlinee that previously would have had no debug info instead of pointing into root). I've only changed this for the call statements and not for the various other statements inserted in this transformation as I need to think more about those first. For the call it seems logical that we do it, especially since we mainly use this information as a "stepping stone" since the devirtualized call should get inlined. No code diffs, only debug info diffs. We see some more entries around devirtualized calls as expected. A lot of the time these diffs look like -IL offs NO_MAP : 0x0000004A ( STACK_EMPTY )
+IL offs 0x0003 : 0x0000004A ( STACK_EMPTY )since we can now associate a statement in an inlinee with the call in the root. cc @dotnet/jit-contrib
|
|
Failure looks unrelated, and the "in progress" job seems to have hit a "System.IO.IOException: No space left on device", not sure why it is still reporting as in progress. |
ghost
locked as resolved and limited conversation to collaborators
Since inlined statements use the IL location of the inliner's statement
all statements created while inlining devirtualized calls would get no
debug info before, while normally these will have IL location pointing
to the call statement in the root.
This behavior seems unwanted and was hard to keep with my upcoming debug info changes since there we are always able to walk back to the root context and get the IL offset from there, and it is hard to check for this particular case (call statement in an inlinee that previously would have had no debug info instead of pointing into root).
I've only changed this for the call statements and not for the various other statements inserted in this transformation as I need to think more about those first. For the call it seems logical that we do it, especially since we mainly use this information as a "stepping stone" since the devirtualized call should get inlined.
No code diffs, only debug info diffs. We see some more entries around devirtualized calls as expected. A lot of the time these diffs look like
since we can now associate a statement in an inlinee with the call in the root.
cc @dotnet/jit-contrib