This is an archive of the discontinued LLVM Phabricator instance.

[InstSimplify] Fold icmp with dominating assume
ClosedPublic

Authored by nikic on Jun 28 2020, 7:24 AM.

Details

Summary

If we assume(x > y), then we should be able to fold the basic implications of that, like x >= y. This already happens if either one of the operands is constant (LVI) or if the conditions are exactly the same (CSE), but not we have an implication with non-constant operands. Support this by querying AssumptionCache.

Fixes https://bugs.llvm.org/show_bug.cgi?id=40149.

Diff Detail

Event Timeline

nikic created this revision.Jun 28 2020, 7:24 AM
Herald added a project: Restricted Project. · View Herald TranscriptJun 28 2020, 7:24 AM
alex added a subscriber: alex.Jun 28 2020, 7:48 AM
spatel added a comment.Jul 1 2020, 8:30 AM

Can we do this in InstSimplify instead? (always folds to constant)

nikic updated this revision to Diff 274926.Jul 1 2020, 2:42 PM
nikic retitled this revision from [InstCombine] Fold icmp with dominating assume to [InstSimplify] Fold icmp with dominating assume.

Move transform from InstCombine into InstSimplify.

nikic added a comment.Jul 1 2020, 2:48 PM

Can we do this in InstSimplify instead? (always folds to constant)

Done! I have some slight compile-time apprehensions about doing this in InstSimplify. On CTMark this is barely above the noise, but that's probably just a result of little assume use in those benchmarks. But I agree that InstSimplify is logically the right place for this, and we can move it, if it becomes a problem.

spatel accepted this revision.Jul 2 2020, 2:06 PM

Can we do this in InstSimplify instead? (always folds to constant)

Done! I have some slight compile-time apprehensions about doing this in InstSimplify. On CTMark this is barely above the noise, but that's probably just a result of little assume use in those benchmarks. But I agree that InstSimplify is logically the right place for this, and we can move it, if it becomes a problem.

Thanks for checking that. Yes, our icmp analysis is known to be expensive, and I remember seeing at least anecdotal evidence that using the assumption cache is also expensive.
So watch out for pushback, but LGTM.

llvm/lib/Analysis/InstructionSimplify.cpp
3287 ↗(On Diff #274926)

Would it make sense to also use "Q.AC.assumptions().empty()" as an early exit?
We use that in InstCombiner::visitSelectInst() to mitigate cost for the presumed common case where there are no assumes available.

This revision is now accepted and ready to land.Jul 2 2020, 2:06 PM
nikic marked an inline comment as done.Jul 2 2020, 2:43 PM
nikic added inline comments.
llvm/lib/Analysis/InstructionSimplify.cpp
3287 ↗(On Diff #274926)

I believe the reason why visitSelectInst() checks for assumptions().empty() is that it does not directly query the assumption cache, but goes through a known bits calculation that takes assumes into account indirectly. In this case we query the assumption cache directly, so if there are no assumes we'll just perform a lookup in an empty hash table.

I wonder if that code in visitSelectInst() is needed at all, as GVN can also perform that fold... EarlyCSE can as well, but not in all cases (as it is conditioned on "SimpleValue::canHandle").

This revision was automatically updated to reflect the committed changes.
dmajor added a subscriber: dmajor.Jul 8 2020, 7:56 AM

After this commit, Firefox builds crash inside the isValidAssumeForContext. I filed https://bugs.llvm.org/show_bug.cgi?id=46638.