Skip to content

JIT: Don't compact away block in cond-to-return folding#113931

Merged
amanasifkhalid merged 1 commit into
dotnet:mainfrom
amanasifkhalid:cond-return-fold-compaction
Mar 26, 2025
Merged

JIT: Don't compact away block in cond-to-return folding#113931
amanasifkhalid merged 1 commit into
dotnet:mainfrom
amanasifkhalid:cond-return-fold-compaction

Conversation

@amanasifkhalid

Copy link
Copy Markdown
Contributor

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.

Copilot AI review requested due to automatic review settings March 26, 2025 17:18
@ghost ghost added the area-CodeGen-coreclr CLR JIT compiler in src/coreclr/src/jit and related components such as SuperPMI label Mar 26, 2025

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

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


retTrueBb = block->GetTrueTarget();
retFalseBb = block->GetFalseTarget();
assert(block->TrueTargetIs(retTrueBb));

Copy link
Copy Markdown
Member

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

Copy link
Copy Markdown
Contributor Author

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.

@EgorBo EgorBo left a comment

Copy link
Copy Markdown
Member

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

// 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))

Copy link
Copy Markdown
Member

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

Copy link
Copy Markdown
Contributor Author

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.

@amanasifkhalid

Copy link
Copy Markdown
Contributor Author

No diffs

@amanasifkhalid

Copy link
Copy Markdown
Contributor Author

/ba-g timeouts on Azure Linux 3 queues

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

area-CodeGen-coreclr CLR JIT compiler in src/coreclr/src/jit and related components such as SuperPMI

Projects

None yet

Development

Successfully merging this pull request may close these issues.

JIT: Assertion failed 'bbTrueEdge->getSourceBlock() == this' during Optimize Bools

3 participants