-
Notifications
You must be signed in to change notification settings - Fork 5k
Fix some missing debug info #62018
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
Fix some missing debug info #62018
Conversation
* Propagate debug info in loop cloning * Do not consume debug info on the standalone call statement created for inline candidates. This would lead to the loss of debugging information for failed inline candidates, since those statements are dropped and expanded in the upcoming GT_RET_EXPR node instead. In some cases it would also lead to the loss of debugging information for successful inlines. In the new logic we allow the same debugging information to be attached to the upcoming statement using the GT_RET_EXPR. This change adds around 40 KB (~0.5%) to SPC.
Tagging subscribers to this area: @JulieLeeMSFT Issue Details
This change adds around 40 KB (~0.5%) to SPC.
|
Same question as in the other PR: any concerns about the size increase? cc @dotnet/jit-contrib @jkotas |
I thought that the size increase in other PR came from the 3rd change (Allow generating more native<->IL mappings mapping) that is dropped in this PR. Is it not the case? What is a good example of debug info delta that leads to the size increase? |
The 3rd point in that PR accounted only for ~5 KB size increase. The vast majority of the size increase is coming because, before this change, we completely lose debug information for any inline candidate that fails to inline sufficiently late in the JIT's analysis. For example: using System;
public static class Program
{
public static void Main()
{
NotInlinedByAnalysis(0);
NotInlinedByAnalysis(1);
NotInlinedByAnalysis(2);
NotInlinedByAnalysis(3);
NotInlinedByAnalysis(4);
}
private static int NotInlinedByAnalysis(int foo)
{
for (int i = 0; i < -Environment.TickCount; i++)
{
for (int j = 0; j < -Environment.TickCount; j++)
{
for (int k = 0; k < -Environment.TickCount; k++)
{
for (int l = 0; l < -Environment.TickCount; l++)
{
System.Console.WriteLine("{0} {1} {2} {3}", i, j, k, l);
}
}
}
}
return 5;
}
} The diff with this change is: ; Assembly listing for method Program:Main()
; Emitting BLENDED_CODE for X64 CPU with AVX - Windows
; optimized code
; rsp based frame
; partially interruptible
; No PGO data
; Final local variable assignments
;
; V00 OutArgs [V00 ] ( 1, 1 ) lclBlk (32) [rsp+00H] "OutgoingArgSpace"
;
; Lcl frame size = 40
G_M27646_IG01:
sub rsp, 40
;; bbWeight=1 PerfScore 0.25
G_M27646_IG02:
+ ; INLRT @ 0x000[E-]
xor ecx, ecx
call Program:NotInlinedByAnalysis(int):int
+ ; INLRT @ 0x007[E-]
mov ecx, 1
call Program:NotInlinedByAnalysis(int):int
+ ; INLRT @ 0x00E[E-]
mov ecx, 2
call Program:NotInlinedByAnalysis(int):int
+ ; INLRT @ 0x015[E-]
mov ecx, 3
call Program:NotInlinedByAnalysis(int):int
+ ; INLRT @ 0x01C[E-]
mov ecx, 4
call Program:NotInlinedByAnalysis(int):int
; INLRT @ 0x023[E-]
nop
;; bbWeight=1 PerfScore 6.50
G_M27646_IG03:
add rsp, 40
ret
;; bbWeight=1 PerfScore 1.25
; Total bytes of code 57, prolog size 4, PerfScore 13.70, instruction count 14, allocated bytes for code 57 (MethodHash=cb019401) for method Program:Main()
; ============================================================
-IP mapping count : 3
+IP mapping count : 8
IL offs PROLOG : 0x00000000 ( STACK_EMPTY )
+IL offs 0x0000 : 0x00000004 ( STACK_EMPTY )
+IL offs 0x0007 : 0x0000000B ( STACK_EMPTY )
+IL offs 0x000E : 0x00000015 ( STACK_EMPTY )
+IL offs 0x0015 : 0x0000001F ( STACK_EMPTY )
+IL offs 0x001C : 0x00000029 ( STACK_EMPTY )
IL offs 0x0023 : 0x00000033 ( STACK_EMPTY )
IL offs EPILOG : 0x00000033 ( STACK_EMPTY )
; Variable debug info: 0 live ranges, 0 vars for method Program:Main() |
Ah ok. No concerns about the size increase from me. |
Propagate debug info in loop cloning
Do not consume debug info on the standalone call statement created for
inline candidates. This would lead to the loss of debugging
information for failed inline candidates, since those statements are
dropped and expanded in the upcoming GT_RET_EXPR node instead. In some
cases it would also lead to the loss of debugging information for
successful inlines.
In the new logic we allow the same debugging information to be
attached to the upcoming statement using the GT_RET_EXPR.
This change adds around 40 KB (~0.5%) to SPC.
Extracted from #61846.