This is split from D105216, but the code is hoisted much earlier into the path where we can actually get a zero stride flowing through. Some fairly simple proofs handle the cases which show up in practice. The only test changes are the cases where we really do need a non-zero divider to produce the right result.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
llvm/lib/Analysis/ScalarEvolution.cpp | ||
---|---|---|
11675 | We make exactly the same isLoopEntryGuardedByCond() call later; can we avoid calling it twice? |
llvm/lib/Analysis/ScalarEvolution.cpp | ||
---|---|---|
11675 | I assume you're concerned about compile time? If so, I'd prefer to land the simple change (this one), and then revisit if needed. I would not be surprised if the later one changed form anyways. |
LGTM
llvm/lib/Analysis/ScalarEvolution.cpp | ||
---|---|---|
11675 | As a practical matter, I'm not really concerned about compile-time here, I guess; we should be hitting wouldZeroStrideBeUB() very rarely in real code. Just feels a little weird. I'm okay landing this as-is for now, and we can consider refactoring once we're confident we're actually performing all the checks we need. |
I've bisected a crash to this change
$ opt -passes='default<O3>' reduced.ll opt: ../../llvm/lib/Analysis/ScalarEvolution.cpp:10521: bool llvm::ScalarEvolution::isLoopEntryGuardedByCond(const llvm::Loop *, ICmpInst::Predica te, const llvm::SCEV *, const llvm::SCEV *): Assertion `isAvailableAtLoopEntry(RHS, L) && "RHS is not available at Loop Entry"' failed.
Maybe we should look at threading the actual branch through to howManyLessThans, so we can use isKnownPredicateAt() or something like that. In the meantime, I'll recommit with an appropriate isLoopInvariant() check.
We make exactly the same isLoopEntryGuardedByCond() call later; can we avoid calling it twice?