JIT: Don't compact away block in cond-to-return folding #113931
Conversation
ghost
added
the
area-CodeGen-coreclr
|
|
||
| retTrueBb = block->GetTrueTarget(); | ||
| retFalseBb = block->GetFalseTarget(); | ||
| assert(block->TrueTargetIs(retTrueBb)); |
There was a problem hiding this comment.
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.
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.
| // 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.
presumably you also don't need !retFalseBb->HasFlag(BBF_REMOVED) check
There was a problem hiding this comment.
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 |
2 participants
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.