-
Notifications
You must be signed in to change notification settings - Fork 4.9k
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
JIT: Don't compact away block in cond-to-return folding #113931
JIT: Don't compact away block in cond-to-return folding #113931
Conversation
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.
Copilot wasn't able to review any files in this pull request.
Files not reviewed (1)
- src/coreclr/jit/optimizebools.cpp: Language not supported
@@ -1720,8 +1721,8 @@ bool Compiler::fgFoldCondToReturnBlock(BasicBlock* block) | |||
return modified; | |||
} | |||
|
|||
retTrueBb = block->GetTrueTarget(); | |||
retFalseBb = block->GetFalseTarget(); | |||
assert(block->TrueTargetIs(retTrueBb)); |
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.
there is Same here - bail out if the block is no longer BBJ_COND after compacting.
comment with a condition that you can remove I presume
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 don't think we can remove this: Suppose the true target jumps to the false target, and we compact the false target into the true target. This will make the conditional block degenerate, since it now branches to the same target in either case. fgReplaceJumpTarget
will detect this, and convert the block into a BBJ_ALWAYS
, so I think we need to check for this case in the caller.
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.
Good catch, totally forgot that BBJ_COND can point to itself
{ | ||
fgCompactBlock(retTrueBb); | ||
modified = true; | ||
} | ||
// By the time we get to the retFalseBb, it might be removed by fgCompactBlock() | ||
// so we need to check if it is still valid. | ||
if (!retFalseBb->HasFlag(BBF_REMOVED) && fgCanCompactBlock(retFalseBb)) | ||
if (!retFalseBb->HasFlag(BBF_REMOVED) && fgCanCompactBlock(retFalseBb) && !retFalseBb->TargetIs(block)) |
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.
presumably you also don't need !retFalseBb->HasFlag(BBF_REMOVED)
check
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 think we still need this too in the case of the diamond shape: If the true target jumps to the false target and we compact them, retFalseBb
will be removed from the flowgraph. This check currently defends against this case.
/ba-g timeouts on Azure Linux 3 queues |
Fixes #113923. If we are considering folding a conditional block with successors that loop back to it, don't try to compact the successors, as that will quietly remove the conditional block from the flowgraph. Instead, skip compaction, and let the cond-to-return shape check fail.