[PATCH] D106852: [SCEV] Fix getAddExpr for adding loop invariants into start of some AddRec
Serguei Katkov via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Tue Jul 27 21:14:19 PDT 2021
skatkov added a comment.
In D106852#2909261 <https://reviews.llvm.org/D106852#2909261>, @skatkov wrote:
> In D106852#2907747 <https://reviews.llvm.org/D106852#2907747>, @efriedma wrote:
>
>> What happens if you just assume is0thIterationGuaranteed is always false? I'm not sure all this work to try to prove the flags is worth doing.
>
> At least no-one LLVM test is failing. Do you propose to just always say that we cannot guarantee 0th iteration?
> I'll update the patch. If it will cause any performance issue we can return to discussion how to detect that 0th iteration is possible.
ok I was too optimistic, I've got 15 failures which will look into
Failed Tests (15):
LLVM :: Analysis/LoopAccessAnalysis/number-of-memchecks.ll
LLVM :: Analysis/LoopAccessAnalysis/reverse-memcheck-bounds.ll
LLVM :: Analysis/ScalarEvolution/flags-from-poison.ll
LLVM :: Analysis/ScalarEvolution/incorrect-exit-count.ll
LLVM :: Analysis/ScalarEvolution/max-backedge-taken-count-guard-info.ll
LLVM :: Analysis/ScalarEvolution/no-wrap-symbolic-becount.ll
LLVM :: Analysis/ScalarEvolution/nsw-offset-assume.ll
LLVM :: Analysis/ScalarEvolution/nsw-offset.ll
LLVM :: Analysis/ScalarEvolution/nsw.ll
LLVM :: Analysis/ScalarEvolution/ptrtoint.ll
LLVM :: Analysis/ScalarEvolution/range_nw_flag.ll
LLVM :: CodeGen/ARM/ParallelDSP/pr42729.ll
LLVM :: Transforms/LoopIdiom/basic.ll
LLVM :: Transforms/LoopStrengthReduce/X86/expander-crashes.ll
LLVM :: Transforms/LoopVectorize/runtime-check-pointer-element-type.ll
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D106852/new/
https://reviews.llvm.org/D106852
More information about the llvm-commits
mailing list