We can prove more predicates when we have a context when eliminating ICmp.
As first (and very obvious) approximation we can use the ICmp instruction itself,
though in the future we are going to use a common dominator of all its users.
Need some refactoring before that.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
llvm/test/Transforms/IndVarSimplify/scev-expander-preserve-lcssa.ll | ||
---|---|---|
119 ↗ | (On Diff #330941) | Looks like it's a bug needs to be fixed before we can go with it. |
llvm/test/Transforms/IndVarSimplify/scev-expander-preserve-lcssa.ll | ||
---|---|---|
119 ↗ | (On Diff #330941) | Funny thing that both false and true are correct here. br i1 %cmp8243, label %for.body84, label %return which is an impossible condition. In fact, this code is unreachable so anything is OK. |
And that's what i was expecting to see: https://llvm-compile-time-tracker.com/compare.php?from=9575c48b8959dae3c3e39e0227435ae6ebd71443&to=c0e80b44e3c80fa9f344b14cbb8435c15f75f94e&stat=instructions
Are the checks already ordered from less costly to more costly?
llvm/test/Transforms/IndVarSimplify/scev-expander-preserve-lcssa.ll | ||
---|---|---|
119 ↗ | (On Diff #330941) | btw this is a lead for further compile time opt that we are missing. Blocks guarded by false conditions can have any predicate proved automatically, to save some time. |
That's sad. I think this is happening because, when false is trivially provable without context, we still spend a lot of time proving true via context. I'll try to find a way around it...
For the compile time concern, one idea you could consider exploring would be to have a version of isKnownPredicateAt which returns an Optional<bool>. Such a routine could use the cheap proof techniques first (in both directions), and then resort to the more expensive ones. In this particular case, it would also simplify the caller code. Looking at a couple other callers, we seem to be missing some optimizations by not asking both.
If we pushed that down all the way to the loop guard processing, that could be a substantial compile time win. (As we'd walk the CFG once, not twice, in the case where we can't prove anything.)
This is a really good way to imrpove this, thank you for bringing this up. I'll consider this.
Rebased on top of new API for predicate evaluation. Now the order of checks should be from cheap to expensive. Hope this is more CT-friendly.
Looks good to me.
It didn't really help, still within the same ballpark +/- noise i would say:
https://llvm-compile-time-tracker.com/compare.php?from=9575c48b8959dae3c3e39e0227435ae6ebd71443&to=c0e80b44e3c80fa9f344b14cbb8435c15f75f94e&stat=instructions
vs
https://llvm-compile-time-tracker.com/compare.php?from=fb04227c7cc3c5ebb3ece90f8ec5c629920eb3af&to=71476f7052b97e7ba9f91624c7fa3d3cbd418aa6&stat=instructions
As discussed in previous SCEV changes, that is probably not a blocker here, although it is not great.
Well, we clearly can produce better code here. Let's hope it's worth it. I'll spend some time trying to understand how we can make SCEV cheaper.
I wrote
https://bugs.llvm.org/show_bug.cgi?id=52327
about a crash starting to happen with this patch.