Use isGuaranteedToTransferExecutionToSuccessor instead of
isSafeToSpeculativelyExecute when seeing whether we can propagate the
information in an assume backwards in isValidAssumeForContext. The
latter is more general - it also allows arbitrary loads/stores - and is
also the condition we want: if our assume is guaranteed to execute, it
condition not holding would be UB.
Details
Diff Detail
- Repository
- rL LLVM
Event Timeline
This looks good, however, you need to either:
- Don't remove isAssumeLikeIntrinsic, but instead, update isGuaranteedToTransferExecutionToSuccessor to call it.
- Update isGuaranteedToTransferExecutionToSuccessor to have the complete list from isAssumeLikeIntrinsic.
Right now, isGuaranteedToTransferExecutionToSuccessor only checks:
return CS.onlyReadsMemory() || CS.onlyAccessesArgMemory() || match(I, m_Intrinsic<Intrinsic::assume>());
(At some point, now that we could use post-dominance, you may want to see if it helps. For starters, anything if control dependent on the entry block is guaranteed to execute)
add annotations to isGuaranteedToTransferExecutionToSuccessor (they were present in isAssumeLikeIntrinsic, which was *another* orthogonal method that tried to obtain the same result)
Can you please add some test cases for this? From the description, it seems like making a variant of the first test in test/Transforms/InstCombine/assume.ll would work (with some load, etc. that isSafeToSpeculativelyExecute won't handle but`isGuaranteedToTransferExecutionToSuccessor`. Also, adding tests for all of the intrinsics in isAssumeLikeIntrinsic would be really helpful (because at some point we'll need to fix the semantics in isGuaranteedToTransferExecutionToSuccessor and we'd like not to regress).
test/Transforms/InstCombine/inevitable.ll | ||
---|---|---|
1 ↗ | (On Diff #113697) | Precommit using utils/update_test_checks tool? |
In the meantime additional users of isAssumeLikeIntrinsic() have been added, so I've switched this to call isAssumeLikeIntrinsic() from isGuaranteedToTransferExecutionToSuccessor() instead. Does this still look good?
test/Transforms/InstCombine/inevitable.ll | ||
---|---|---|
1 ↗ | (On Diff #113697) | Done! |
@uenoku This looks like sth. the Attributor should do as well (at some point), I mean use llvm.assume information
Remove isAssumeLikeIntrinsic handling, this is now handled by willreturn attributes on intrinsics.
I suspect that if this is rewritten with MustBeExecutedContextExplorer, @jdoerfert would review.
That depends on the use case. I think we should use the explorer either way but initially in "block-only" mode, which is what is happening here.
One can then decide if more elaborate modes make sense.
For now, I'd be fine with not using the explorer to not block this. In fact, this looks good to me.