[llvm-bugs] [Bug 51179] New: "Trip Count for Loop at depth 1 containing: %for.cond1415<header><exiting>, %for.body1419<latch> Changed!" with verify<scalar-evolution>

via llvm-bugs llvm-bugs at lists.llvm.org
Tue Oct 26 01:34:22 PDT 2021


            Bug ID: 51179
           Summary: "Trip Count for Loop at depth 1 containing:
                    Changed!" with verify<scalar-evolution>
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Loop Optimizer
          Assignee: unassignedbugs at nondot.org
          Reporter: mikael.holmen at ericsson.com
                CC: listmail at philipreames.com, llvm-bugs at lists.llvm.org
                CC: listmail at philipreames.com
           Summary: "Trip Count for Loop at depth 1 containing:
                    Changed!" with verify<scalar-evolution>

Created attachment 25051
  --> https://bugs.llvm.org/attachment.cgi?id=25051&action=edit

llvm commit: 989bedec7a6a

Reproduce with:
 opt -passes='function(loop-mssa(indvars),verify<scalar-evolution>)' -o
/dev/null bbi-58443.ll

Trip Count for Loop at depth 1 containing:
Old: 1
New: 0
Delta: 1
PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash
Stack dump:
0.      Program arguments: build-all-builtins/bin/opt
-passes=function(loop-mssa(indvars),verify<scalar-evolution>) -o /dev/null
 #0 0x0000000002aabec3 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int)
 #1 0x0000000002aa9b3e llvm::sys::RunSignalHandlers()
 #2 0x0000000002aac246 SignalHandler(int) Signals.cpp:0:0
 #3 0x00007fc5aaae9630 __restore_rt sigaction.c:0:0
 #4 0x00007fc5a821c387 raise (/lib64/libc.so.6+0x36387)
 #5 0x00007fc5a821da78 abort (/lib64/libc.so.6+0x37a78)
 #6 0x0000000001b81b95 llvm::ScalarEvolution::verify() const
 #7 0x0000000001b830e1 llvm::ScalarEvolutionVerifierPass::run(llvm::Function&,
llvm::AnalysisManager<llvm::Function>&) (build-all-builtins/bin/opt+0x1b830e1)
 #8 0x0000000002dab4ed llvm::detail::PassModel<llvm::Function,
llvm::ScalarEvolutionVerifierPass, llvm::PreservedAnalyses,
llvm::AnalysisManager<llvm::Function> >::run(llvm::Function&,
llvm::AnalysisManager<llvm::Function>&) crtstuff.c:0:0
 #9 0x0000000002293065 llvm::PassManager<llvm::Function,
llvm::AnalysisManager<llvm::Function> >::run(llvm::Function&,
llvm::AnalysisManager<llvm::Function>&) (build-all-builtins/bin/opt+0x2293065)
#10 0x0000000000ac733d llvm::detail::PassModel<llvm::Function,
llvm::PassManager<llvm::Function, llvm::AnalysisManager<llvm::Function> >,
llvm::PreservedAnalyses, llvm::AnalysisManager<llvm::Function>
>::run(llvm::Function&, llvm::AnalysisManager<llvm::Function>&) crtstuff.c:0:0
#11 0x0000000002297346 llvm::ModuleToFunctionPassAdaptor::run(llvm::Module&,
llvm::AnalysisManager<llvm::Module>&) (build-all-builtins/bin/opt+0x2297346)
#12 0x00000000007952bd llvm::detail::PassModel<llvm::Module,
llvm::ModuleToFunctionPassAdaptor, llvm::PreservedAnalyses,
llvm::AnalysisManager<llvm::Module> >::run(llvm::Module&,
llvm::AnalysisManager<llvm::Module>&) crtstuff.c:0:0
#13 0x0000000002292258 llvm::PassManager<llvm::Module,
llvm::AnalysisManager<llvm::Module> >::run(llvm::Module&,
llvm::AnalysisManager<llvm::Module>&) (build-all-builtins/bin/opt+0x2292258)
#14 0x000000000078d620 llvm::runPassPipeline(llvm::StringRef, llvm::Module&,
llvm::TargetMachine*, llvm::TargetLibraryInfoImpl*, llvm::ToolOutputFile*,
llvm::ToolOutputFile*, llvm::ToolOutputFile*, llvm::StringRef,
llvm::ArrayRef<llvm::StringRef>, llvm::opt_tool::OutputKind,
llvm::opt_tool::VerifierKind, bool, bool, bool, bool, bool)
#15 0x000000000079ff05 main (build-all-builtins/bin/opt+0x79ff05)
#16 0x00007fc5a8208555 __libc_start_main (/lib64/libc.so.6+0x22555)
#17 0x000000000078843c _start (build-all-builtins/bin/opt+0x78843c)

This starts happening with commit fff1363ba0ae5
    [SCEV] Add false->any implication

    By definition of Implication operator, `false -> true` and `false ->
false`. It means that
    `false` implies any predicate, no matter true or false. We don't need to go
any further
    trying to prove the statement we need and just always say that `false`
implies it in this case.

    In practice it means that we are trying to prove something guarded by
`false` condition,
    which means that this code is unreachable, and we can safely prove any fact
or perform any
    transform in this code.

    Differential Revision: https://reviews.llvm.org/D98706
    Reviewed By: lebedev.ri

--- Comment #1 from Mikael Holmén <mikael.holmen at ericsson.com> ---
*** Bug 51180 has been marked as a duplicate of this bug. ***

--- Comment #2 from listmail at philipreames.com ---
This one is tricky and subtle.  I'm leaning towards calling this a verifier
bug.  It's definitely not specific to the triggering patch though.

We've proven that the code is unreachable, and any transformation is legal on
unreachable code.  The transformation being done here *wouldn't* be legal if
the loop in question was reachable, but since it's dead, all bets are off.

Unfortunately, it's hard to see a small fix for the verifier here.  In this
case, the fact the loop is unreachable is "obvious", but in general, it could
be hidden in an arbitrarily complex way that SCEV happened to understand.  So,
it's not as simple as trying to restrict the verifier to reachable loops.

We could probably mask this particular false positive easily enough, but I
don't see a good general solution here.

You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20211026/c0597348/attachment-0001.html>

More information about the llvm-bugs mailing list