[llvm-bugs] [Bug 49967] New: opt -enable-new-pm=0 -loop-deletion fails with Assertion `!isInvalid() && "Loop not in a valid state!"' failed.

via llvm-bugs llvm-bugs at lists.llvm.org
Wed Apr 14 23:49:42 PDT 2021


https://bugs.llvm.org/show_bug.cgi?id=49967

            Bug ID: 49967
           Summary: opt -enable-new-pm=0 -loop-deletion fails with
                    Assertion `!isInvalid() && "Loop not in a valid
                    state!"' failed.
           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: llvm-bugs at lists.llvm.org

Created attachment 24755
  --> https://bugs.llvm.org/attachment.cgi?id=24755&action=edit
bbi-55148.ll reproducer

llvm commit: c3f12714641

Reproduce with:
 opt -enable-new-pm=0 -loop-deletion -o /dev/null bbi-55148.ll

Result:
opt: ../include/llvm/Analysis/LoopInfo.h:123: bool
llvm::LoopBase<llvm::BasicBlock, llvm::Loop>::contains(const LoopT *) const
[BlockT = llvm::BasicBlock, LoopT = llvm::Loop]: Assertion `!isInvalid() &&
"Loop not in a valid state!"' failed.
PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash
backtrace.
Stack dump:
0.      Program arguments: /repo/uabelho/master-github/llvm/build-all/bin/opt
-enable-new-pm=0 -loop-deletion -o /dev/null bbi-55148.ll
1.      Running pass 'Function Pass Manager' on module 'bbi-55148.ll'.
2.      Running pass 'Loop Pass Manager' on function '@test'
3.      Running pass 'Delete dead loops' on basic block '%vector.ph'
Stack dump without symbol names (ensure you have llvm-symbolizer in your PATH
or set the environment var `LLVM_SYMBOLIZER_PATH` to point to it):
/repo/uabelho/master-github/llvm/build-all/bin/opt(_ZN4llvm3sys15PrintStackTraceERNS_11raw_ostreamEi+0x23)[0x294f683]
/repo/uabelho/master-github/llvm/build-all/bin/opt(_ZN4llvm3sys17RunSignalHandlersEv+0xee)[0x294d33e]
/repo/uabelho/master-github/llvm/build-all/bin/opt[0x294fb46]
/lib64/libpthread.so.0(+0xf630)[0x7f8cb537e630]
/lib64/libc.so.6(gsignal+0x37)[0x7f8cb2ab1387]
/lib64/libc.so.6(abort+0x148)[0x7f8cb2ab2a78]
/lib64/libc.so.6(+0x2f1a6)[0x7f8cb2aaa1a6]
/lib64/libc.so.6(+0x2f252)[0x7f8cb2aaa252]
/repo/uabelho/master-github/llvm/build-all/bin/opt(_ZN4llvm15ScalarEvolution18computeSCEVAtScopeEPKNS_4SCEVEPKNS_4LoopE+0xf76)[0x1aa7116]
/repo/uabelho/master-github/llvm/build-all/bin/opt(_ZN4llvm15ScalarEvolution14getSCEVAtScopeEPKNS_4SCEVEPKNS_4LoopE+0x7c)[0x1a9f2cc]
/repo/uabelho/master-github/llvm/build-all/bin/opt(_ZN4llvm15ScalarEvolution24computeExitLimitFromICmpEPKNS_4LoopEPNS_8ICmpInstEbbb+0x9a)[0x1a9d77a]
/repo/uabelho/master-github/llvm/build-all/bin/opt(_ZN4llvm15ScalarEvolution28computeExitLimitFromCondImplERNS0_14ExitLimitCacheEPKNS_4LoopEPNS_5ValueEbbb+0xd8)[0x1a9cee8]
/repo/uabelho/master-github/llvm/build-all/bin/opt(_ZN4llvm15ScalarEvolution30computeExitLimitFromCondCachedERNS0_14ExitLimitCacheEPKNS_4LoopEPNS_5ValueEbbb+0xe7)[0x1a9ca27]
/repo/uabelho/master-github/llvm/build-all/bin/opt(_ZN4llvm15ScalarEvolution16computeExitLimitEPKNS_4LoopEPNS_10BasicBlockEb+0x5d0)[0x1a9c140]
/repo/uabelho/master-github/llvm/build-all/bin/opt(_ZN4llvm15ScalarEvolution25computeBackedgeTakenCountEPKNS_4LoopEb+0x290)[0x1a98c10]
/repo/uabelho/master-github/llvm/build-all/bin/opt(_ZN4llvm15ScalarEvolution20getBackedgeTakenInfoEPKNS_4LoopE+0x1ba)[0x1a9738a]
/repo/uabelho/master-github/llvm/build-all/bin/opt(_ZN4llvm15ScalarEvolution21getBackedgeTakenCountEPKNS_4LoopENS0_13ExitCountKindE+0x24)[0x1a983f4]
/repo/uabelho/master-github/llvm/build-all/bin/opt[0x26d5f6c]
/repo/uabelho/master-github/llvm/build-all/bin/opt(_ZN4llvm13LPPassManager13runOnFunctionERNS_8FunctionE+0x75b)[0x19eb04b]
/repo/uabelho/master-github/llvm/build-all/bin/opt(_ZN4llvm13FPPassManager13runOnFunctionERNS_8FunctionE+0x47f)[0x2155e5f]
/repo/uabelho/master-github/llvm/build-all/bin/opt(_ZN4llvm13FPPassManager11runOnModuleERNS_6ModuleE+0x38)[0x215c7b8]
/repo/uabelho/master-github/llvm/build-all/bin/opt(_ZN4llvm6legacy15PassManagerImpl3runERNS_6ModuleE+0x35d)[0x215642d]
/repo/uabelho/master-github/llvm/build-all/bin/opt(main+0x3137)[0x7808a7]
/lib64/libc.so.6(__libc_start_main+0xf5)[0x7f8cb2a9d555]
/repo/uabelho/master-github/llvm/build-all/bin/opt[0x76b8f5]
Abort

This starts happening with commit faf9f11589ce:
    [SCEV] Don't walk uses of phis without SCEV expression when forgetting

    I've run into some cases where a large fraction of compile-time is
    spent invalidating SCEV. One of the causes is forgetLoop(), which
    walks all values that are def-use reachable from the loop header
    phis. When invalidating a topmost loop, that might be close to all
    values in a function. Additionally, it's fairly common for there to
    not actually be anything to invalidate, but we'll still be performing
    this walk again and again.

    My first thought was that we don't need to continue walking the uses
    if the current value doesn't have a SCEV expression. However, this
    isn't quite right, because SCEV construction can skip over values
    (e.g. for a chain of adds, we might only create a SCEV expression
    for the final value).

    What this patch does instead is to only walk the (full) def-use chain
    of loop phis that have a SCEV expression. If there's no expression
    for a phi, then we also don't have any dependent expressions to
    invalidate.

    Differential Revision: https://reviews.llvm.org/D100264

-- 
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/20210415/8f32bb5b/attachment.html>


More information about the llvm-bugs mailing list