Amended the GEP check in checkOverflow to ensure that the GEP
dominates the loop latch. If the GEP doesn't dominate the latch
then it is not necessarily calculated on each loop iteration, so
the assumption that the GEP will overflow (and be UB) before the
IV no longer holds.
Details
- Reviewers
dmgreen SjoerdMeijer - Commits
- rGd1aa075129a9: [LoopFlatten] Fix assertion failure
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
I think this needs to check that the GEP is used by a load/store that is executed on each iteration.
Can this use one of the isGuaranteedToExecute function too? There is a isGuaranteedToExecuteForEveryIteration, but it does not look very powerful. It may be OK for most loops though, where checking the inner loop header is enough.
Changed the check to see if the GEP is used by a load/store instruction
and, if so, isGuaranteedToExecuteForEveryIteration is used with the instruction and
inner loop to determine if the GEP dominates the latch.
Hopefully this change is what you had in mind - I'm just not sure whether the
if (isa<LoadInst>(GEPUser) || isa<StoreInst>(GEPUser))
is necessary (can a GEP be used by something that isn't a store or a load?)
Yeah, sounds good to me. There is quite a bit of nesting, but I hope it will be rare to get into it, or quick when it does usually finding the UB on the first item it visits.
Yeah sounds good. Can you add one extra check that the Store is using the GEP for the address, not the stored value. So it is operand #1, not #0.
llvm/lib/Transforms/Scalar/LoopFlatten.cpp | ||
---|---|---|
501 | It may be better to reverse the condition so that we reduce the indentation and don't require GEPDominatesLatch any more. if (!isa<Load>(..) && !isa<Store>(..)) continue; if (!isGuaranteedToExecuteForEveryIteration(..)) continue; |
- Added check that GEP is used as address of store instruction
- Reversed logic in some places and removed GEPDominatesLatch
It may be better to reverse the condition so that we reduce the indentation and don't require GEPDominatesLatch any more.