This is an archive of the discontinued LLVM Phabricator instance.

[llvm-reduce] improve bb removal
ClosedPublic

Authored by markus on May 17 2022, 5:13 AM.

Details

Summary

Currently the llvm-reduce basic-blocks pass has the habit of replacing branches with ret instructions if the sole branch target of a block has been removed. Replacing a br with a ret results in a radically different CFG that might very well fail to reproduce what we are currently trying to reduce, especially if it is loop dependent. As a result going down these paths is seldom fruitful and we are left with block sequences like the following in the final reduction

cont5830:                                         ; preds = %for.body5828
  br label %for.cond5831

for.cond5831:                                     ; preds = %cont5830
  br label %cont5833

cont5833:                                         ; preds = %for.cond5831
  br label %for.end6075

for.end6075:                                      ; preds = %cont5833
  br label %cont6078

cont6078:                                         ; preds = %for.end6075
  br label %cont6080

cont6080:                                         ; preds = %cont6078
  br label %for.cond5821

This patch instead tries to update the branch to target the next block in sequence that is not to be removed thus increasing the likelihood of still maintaining a loop (while getting rid of some useless sequential flow). Probably we should go further than this and use loop analysis to make sure not to break loop structures but until then this small change seems like a step in the right direction.

Diff Detail

Event Timeline

markus created this revision.May 17 2022, 5:13 AM
Herald added a project: Restricted Project. · View Herald TranscriptMay 17 2022, 5:13 AM
markus requested review of this revision.May 17 2022, 5:13 AM
Herald added a project: Restricted Project. · View Herald TranscriptMay 17 2022, 5:13 AM
aeubanks accepted this revision.May 18 2022, 9:32 AM

seems reasonable

This revision is now accepted and ready to land.May 18 2022, 9:32 AM
arsenm added a subscriber: arsenm.May 18 2022, 9:35 AM

If you blindly scan forward, you're going to run into blocks that have phis that are now missing an input for the new predecessor

arsenm requested changes to this revision.May 18 2022, 2:02 PM
This revision now requires changes to proceed.May 18 2022, 2:02 PM

If you blindly scan forward, you're going to run into blocks that have phis that are now missing an input for the new predecessor

Yes, absolutely. Since IR verification happens afterwards the reduction is still going to be rejected but of course if we take more care then we can find a reduction that has less risk of failing verification and might lead us down a fruitful path.
So in a way I would consider this an improvement over the current behavior anyway but while we are at it can certainly be improved a bit further. Will address that.

markus updated this revision to Diff 430609.May 19 2022, 2:25 AM

Do not branch to blocks with existing phi-node.

aeubanks accepted this revision.May 20 2022, 11:08 AM

@arsenm, is this what you had in mind wrt phi-nodes or were you requesting some more elaborate change?

arsenm accepted this revision.May 23 2022, 6:50 AM

This isn’t the change I expected but should work for now. I’m working on the machine equivalent of this reduction now and may make additional changes here

This revision is now accepted and ready to land.May 23 2022, 6:50 AM

I’m working on the machine equivalent of this reduction now and may make additional changes here

Sounds good. There might even be opportunity for some common code (or at least strategy) between IR and MIR here.

This revision was landed with ongoing or failed builds.May 24 2022, 12:53 AM
This revision was automatically updated to reflect the committed changes.