This is an archive of the discontinued LLVM Phabricator instance.

[IPSCCP] Support unfeasible default dests for switch.
ClosedPublic

Authored by fhahn on Nov 9 2021, 10:40 AM.

Details

Summary

At the moment, unfeasible default destinations are not handled properly
in removeNonFeasibleEdges. So far, only unfeasible cases are removed,
but later code expects unreachable blocks to have no predecessors.

This is causing the crash reported in PR49573.

If the default destination is unfeasible it won't be executed. Create
a new unreachable block on demand and use that as default
destination.

Note that at the moment this only is relevant for cases where
resolvedUndefsIn marks the first case as executable. Regular switch
handling has a FIXME/TODO to support determining whether the default
case is feasible or not.

Diff Detail

Event Timeline

fhahn created this revision.Nov 9 2021, 10:40 AM
fhahn requested review of this revision.Nov 9 2021, 10:40 AM
Herald added a project: Restricted Project. · View Herald TranscriptNov 9 2021, 10:40 AM

Not really familiar with this pass, but the transform sounds legal, although i would have guessed you'd want to instead point it to an new block with unreachable?

nikic added a comment.Nov 25 2021, 9:20 AM

Agree with @lebedev.ri, this should point to an unreachable block. It doesn't matter much for the resolvedUndefsIn case, but with proper support merging into an unrelated case would be a pretty bad choice.

fhahn updated this revision to Diff 390028.Nov 26 2021, 5:18 AM

Not really familiar with this pass, but the transform sounds legal, although i would have guessed you'd want to instead point it to an new block with unreachable?

! In D113497#3154265, @nikic wrote:

Agree with @lebedev.ri, this should point to an unreachable block. It doesn't matter much for the resolvedUndefsIn case, but with proper support merging into an unrelated case would be a pretty bad choice.

Thanks, I updated the code to create a new unreachable block on demand (and cache it for the function) and use that as default successor.

fhahn edited the summary of this revision. (Show Details)Nov 26 2021, 5:19 AM
lebedev.ri accepted this revision.Nov 26 2021, 5:32 AM

LG.

If SCCP runs again, will it then again create a new unreachable block
for the default that is already pointing at the unreachable block?
Should it not do such redundant work?

This revision is now accepted and ready to land.Nov 26 2021, 5:32 AM
fhahn added a comment.Nov 29 2021, 3:09 AM

LG.

If SCCP runs again, will it then again create a new unreachable block
for the default that is already pointing at the unreachable block?
Should it not do such redundant work?

Good point. In practice I think IPSCCP is only run twice when doing LTO, so it's probably not a big deal. But let me check if the default dst is already unreachable.

This revision was automatically updated to reflect the committed changes.
Herald added a project: Restricted Project. · View Herald TranscriptApr 26 2022, 4:41 AM
fhahn added a comment.Apr 26 2022, 4:43 AM

LG.

If SCCP runs again, will it then again create a new unreachable block
for the default that is already pointing at the unreachable block?
Should it not do such redundant work?

Good point. In practice I think IPSCCP is only run twice when doing LTO, so it's probably not a big deal. But let me check if the default dst is already unreachable.

If the default destination is already only an unreachable block and unfeasible, it the original block will be removed as part of the clean-up. re-using the block would be difficult, because it's been already marked for deletion and I think making changes to that is probably not worth the trouble.