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.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
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 | Would it make sense to also use "Q.AC.assumptions().empty()" as an early exit? |
llvm/lib/Analysis/InstructionSimplify.cpp | ||
---|---|---|
3287 | 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"). |
After this commit, Firefox builds crash inside the isValidAssumeForContext. I filed https://bugs.llvm.org/show_bug.cgi?id=46638.
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.