-
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
Simplify JIT label handling #51208
Simplify JIT label handling #51208
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -93,14 +93,6 @@ void CodeGen::genInitialize() | |
initializeVariableLiveKeeper(); | ||
#endif // USING_VARIABLE_LIVE_RANGE | ||
|
||
// The current implementation of switch tables requires the first block to have a label so it | ||
// can generate offsets to the switch label targets. | ||
// TODO-CQ: remove this when switches have been re-implemented to not use this. | ||
if (compiler->fgHasSwitch) | ||
{ | ||
compiler->fgFirstBB->bbFlags |= BBF_JMP_TARGET; | ||
} | ||
|
||
genPendingCallLabel = nullptr; | ||
|
||
// Initialize the pointer tracking code | ||
|
@@ -167,8 +159,7 @@ void CodeGen::genCodeForBBlist() | |
|
||
#endif // defined(DEBUG) && defined(TARGET_XARCH) | ||
|
||
// Prepare the blocks for exception handling codegen: mark the blocks that needs labels. | ||
genPrepForEHCodegen(); | ||
genMarkLabelsForCodegen(); | ||
|
||
assert(!compiler->fgFirstBBScratch || | ||
compiler->fgFirstBB == compiler->fgFirstBBScratch); // compiler->fgFirstBBScratch has to be first. | ||
|
@@ -321,7 +312,7 @@ void CodeGen::genCodeForBBlist() | |
|
||
// If this block is a jump target or it requires a label then set 'needLabel' to true, | ||
// | ||
bool needLabel = (block->bbFlags & (BBF_JMP_TARGET | BBF_HAS_LABEL)) != 0; | ||
bool needLabel = (block->bbFlags & BBF_HAS_LABEL) != 0; | ||
|
||
if (block == compiler->fgFirstColdBlock) | ||
{ | ||
|
@@ -758,12 +749,24 @@ void CodeGen::genCodeForBBlist() | |
// | ||
// During emitter, this information will be used to calculate the loop size. | ||
// Depending on the loop size, decision of whether to align a loop or not will be taken. | ||
// | ||
// In the emitter, we need to calculate the loop size from `block->bbJumpDest` through | ||
// `block` (inclusive). Thus, we need to ensure there is a label on the lexical fall-through | ||
// block, even if one is not otherwise needed, to be able to calculate the size of this | ||
// loop (loop size is calculated by walking the instruction groups; see emitter::getLoopSize()). | ||
|
||
if (block->bbJumpDest->isLoopAlign()) | ||
{ | ||
GetEmitter()->emitSetLoopBackEdge(block->bbJumpDest); | ||
|
||
if (block->bbNext != nullptr) | ||
{ | ||
JITDUMP("Mark " FMT_BB " as label: alignment end-of-loop\n", block->bbNext->bbNum); | ||
block->bbNext->bbFlags |= BBF_HAS_LABEL; | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Shouldn't this be an assert that There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. No, this is a case where the following block will not necessarily have a label. It was always true that fall-through flow doesn't require a label, but before there were more cases where it "accidentally" did have a label. The alignment code never specified that it needed a label, so it would calculate loop sizes based on whatever happened to be the next label. After my change, we have fewer labels, so some loops ended up "too large" for alignment. Here, I force the label to exist when we know alignment wants one, for calculating loop sizes. The one possibility is I could move this setting to There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Yes, we should definitely compare loopsAligned before and after to make sure we are aligning right amount of loops with this change. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Over aspnet/benchmarks/libraries.crossgen/tests SPMI collections, I see loops/align candidates/loops aligned of 6135/1550/647 for baseline and the same bug 646 loops aligned for diff (my change). So it appears that exactly one fewer loop was aligned. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Interesting. Did you figure out the CI failure and is it related? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The assertion was due to the JIT deciding a loop was no longer a loop, then compacting the preheader with the former loop head, moving the align bit with the merge (with my new code). But since the (former) loop head no longer was the target of any branch, it didn't get a label. Solution: remove the align bit when this optimization happens. |
||
} | ||
} | ||
#endif | ||
#endif // FEATURE_LOOP_ALIGN | ||
|
||
break; | ||
|
||
default: | ||
|
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.