[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