-
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
Improve LSRA and other dump output #71499
Conversation
E.g., Update LSRA "Allocating Registers" table description. Dump nodes added during resolution, e.g.: ``` BB29 bottom (BB08->BB08): move V25 from STK to rdi (Critical) N001 ( 1, 1) [001174] ----------z t1174 = LCL_VAR int V25 cse4 rdi REG rdi ``` Dump more data in the LSRA block sequence data: ``` -BB03( 16 ) -BB04( 4 ) +BB03 ( 16 ) critical-in critical-out +BB04 ( 4 ) critical-out ``` When dumping various flow bitvectors, annotate the bitvectors better: ``` -BB25 in gen out -0000000000000000 -0000000000000003 CSE #1.c -0000000000000003 CSE #1.c +BB25 + in: 0000000000000000 +gen: 0000000000000003 CSE #1.c +out: 0000000000000003 CSE #1.c ``` Dump hoisting bitvectors using the sorting number: ``` - USEDEF (5)={V04 V00 V01 V02 V03} + USEDEF (5)={V00 V01 V02 V03 V04} ``` Also, fix various typos and formatting.
Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch Issue DetailsE.g., Update LSRA "Allocating Registers" table description. Dump nodes added during resolution, e.g.:
Dump more data in the LSRA block sequence data:
When dumping various flow bitvectors, annotate the bitvectors better:
Dump hoisting bitvectors using the function which sorts on local number:
Also, fix various typos and formatting.
|
@kunalspathak @dotnet/jit-contrib PTAL |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for doing this. Added some minor questions/suggestions.
@@ -1194,7 +1194,7 @@ struct GenTree | |||
return (gtOper == GT_LCL_FLD || gtOper == GT_LCL_FLD_ADDR || gtOper == GT_STORE_LCL_FLD); | |||
} | |||
|
|||
inline bool OperIsLocalField() const |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why this change?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
inline
is implicit for function definitions within the body of a class declaration, so this is just to be consistent with all other cases that don't use it.
@@ -2110,13 +2110,13 @@ void LinearScan::buildIntervals() | |||
printf("-----------------\n"); | |||
for (BasicBlock* const block : compiler->Blocks()) | |||
{ | |||
printf(FMT_BB " use def in out\n", block->bbNum); | |||
printf(FMT_BB "\nuse: ", block->bbNum); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
love this
} | ||
#elif defined(TARGET_ARM) | ||
if (frameSize > 0x0400) | ||
{ | ||
// We likely have a large stack frame. | ||
// | ||
// Thus we might need to use large displacements when loading or storing | ||
// to CSE LclVars that are not enregistered |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Curious, how do you spot these? Do you have a tool or something to scan the files?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just reading code.
const LsraBlockInfo& bi = blockInfo[block->bbNum]; | ||
|
||
// Note that predBBNum isn't set yet. | ||
JITDUMP(" (%6s)", refCntWtd2str(bi.weight)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Remind me, but block->getBBWeight() == bi.weight
and hence this change is same as what he had until now?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Exactly: no change to the output
JITDUMP(" " FMT_BB " %s", block->bbNum, insertionPointString); | ||
if (toBlock == nullptr) | ||
{ | ||
// SharedCritical resolution has no `toBlock`. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
May be helpful to print about SharedCritical
and fromBlock
at least?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wasn't sure what to do about SharedCritical so I kind-of punted. I believe the "from" block is the one that gets printed anyway.
E.g.,
Update LSRA "Allocating Registers" table description. Now:
Dump nodes added during resolution, e.g.:
Dump more data in the LSRA block sequence data:
When dumping various flow bitvectors, annotate the bitvectors better:
Dump hoisting bitvectors using the function which sorts on local number:
Also, fix various typos and formatting.