This is an archive of the discontinued LLVM Phabricator instance.

[LICM] Compute a must execute property for the prefix of the header as we go
ClosedPublic

Authored by reames on Apr 27 2018, 2:23 PM.

Details

Reviewers
mkazantsev
anna
Summary

Computing this property within the existing walk ensures that the cost is linear with the size of the block. If we did this from within isGuaranteedToExecute, it would be quadratic without some very fancy caching.

This allows us to reliably catch a hoistable instruction within a header which may throw at some point *after* our hoistable instruction. It doesn't do anything for non-header cases, but given how common single block loops are, this seems very worthwhile.

(The rest of this is not part of the commit message, just recording ideas.)

Given this, we could expand in a couple of directions:

  • special case a guard which is known not to be taken on the first iteration of the loop
  • support hoisting of guards themselves if we compute an extra IsPrefixReadOnly property as we go.
  • I'm seriously considering keeping around the set of loop blocks with implicit control flow in LoopSafetyInfo. Doing so would let us apply a variation of the exit logic combined with this prefix property to handle non-header cases as well.

Diff Detail

Event Timeline

reames created this revision.Apr 27 2018, 2:23 PM
mkazantsev accepted this revision.May 2 2018, 7:31 PM

LGTM once comments are addressed.

lib/Transforms/Scalar/LICM.cpp
490

Here we create some instructions. I think all of them are fine, but doesn't it make sense to assert that each of them transfers execution to successor? Just in case this logic ever changes.

508

If hoist was successful, we don't actually need to make isGuaranteedToTransferExecutionToSuccessor check on the instruction that is no longer in this block. Maybe replace with assert in this case?

This revision is now accepted and ready to land.May 2 2018, 7:31 PM
reames added inline comments.May 4 2018, 12:43 PM
lib/Transforms/Scalar/LICM.cpp
508

I need to add a continue after the hoist. (In theory, we hoist instructions that aren't guaranteed to transfer control to their successors - we don't today, but might.) Will fix.

reames closed this revision.May 4 2018, 2:40 PM

Committed revision 331557.