[llvm-bugs] [Bug 49950] New: opt crashes with "opt -enable-new-pm=0 -o /dev/null bbi-55010.ll -block-freq -opt-remark-emitter -memoryssa -inject-tli-mappings -pgo-memop-opt -verify-loop-info"
via llvm-bugs
llvm-bugs at lists.llvm.org
Tue Apr 13 04:31:32 PDT 2021
https://bugs.llvm.org/show_bug.cgi?id=49950
Bug ID: 49950
Summary: opt crashes with "opt -enable-new-pm=0 -o /dev/null
bbi-55010.ll -block-freq -opt-remark-emitter
-memoryssa -inject-tli-mappings -pgo-memop-opt
-verify-loop-info"
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 24748
--> https://bugs.llvm.org/attachment.cgi?id=24748&action=edit
bbi-55010.ll reproducer
llvm commit: 808a5a2534cd
Reproduce with:
opt -enable-new-pm=0 -o /dev/null bbi-55010.ll -block-freq -opt-remark-emitter
-memoryssa -inject-tli-mappings -pgo-memop-opt -verify-loop-info
Result:
PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash
backtrace.
Stack dump:
0. Program arguments: build-all-Debug/bin/opt -enable-new-pm=0 -o
/dev/null bbi-55010.ll -block-freq -opt-remark-emitter -memoryssa
-inject-tli-mappings -pgo-memop-opt -verify-loop-info
1. Running pass 'Function Pass Manager' on module 'bbi-55010.ll'.
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):
build-all-Debug/bin/opt(_ZN4llvm3sys15PrintStackTraceERNS_11raw_ostreamEi+0x3c)[0x43efdac]
build-all-Debug/bin/opt[0x43eff7b]
build-all-Debug/bin/opt(_ZN4llvm3sys17RunSignalHandlersEv+0x76)[0x43ee4e6]
build-all-Debug/bin/opt[0x43f06e7]
/lib64/libpthread.so.0(+0xf630)[0x7f889d79d630]
build-all-Debug/bin/opt[0x3712aec]
build-all-Debug/bin/opt(_ZNK4llvm15DomTreeNodeBaseINS_10BasicBlockEE5beginEv+0x19)[0x3712ad9]
build-all-Debug/bin/opt[0x2bf0d25]
build-all-Debug/bin/opt[0x2bf0b5e]
build-all-Debug/bin/opt[0x2bf0acf]
build-all-Debug/bin/opt(_ZN4llvm8po_beginIPKNS_15DomTreeNodeBaseINS_10BasicBlockEEEEENS_11po_iteratorIT_NS_11SmallPtrSetINS_11GraphTraitsIS7_E7NodeRefELj8EEELb0ESA_EERKS7_+0x1f)[0x2bf016f]
build-all-Debug/bin/opt(_ZN4llvm10post_orderIPKNS_15DomTreeNodeBaseINS_10BasicBlockEEEEENS_14iterator_rangeINS_11po_iteratorIT_NS_11SmallPtrSetINS_11GraphTraitsIS8_E7NodeRefELj8EEELb0ESB_EEEERKS8_+0x33)[0x2be2a03]
build-all-Debug/bin/opt(_ZN4llvm12LoopInfoBaseINS_10BasicBlockENS_4LoopEE7analyzeERKNS_17DominatorTreeBaseIS1_Lb0EEE+0x3b)[0x2be275b]
build-all-Debug/bin/opt(_ZNK4llvm12LoopInfoBaseINS_10BasicBlockENS_4LoopEE6verifyERKNS_17DominatorTreeBaseIS1_Lb0EEE+0x2dd)[0x2be312d]
build-all-Debug/bin/opt(_ZNK4llvm19LoopInfoWrapperPass14verifyAnalysisEv+0x58)[0x2bdae88]
build-all-Debug/bin/opt(_ZN4llvm13PMDataManager23verifyPreservedAnalysisEPNS_4PassE+0xbd)[0x37d656d]
build-all-Debug/bin/opt(_ZN4llvm13FPPassManager13runOnFunctionERNS_8FunctionE+0x490)[0x37d3790]
build-all-Debug/bin/opt(_ZN4llvm13FPPassManager11runOnModuleERNS_6ModuleE+0x75)[0x37d8875]
build-all-Debug/bin/opt[0x37d3f18]
build-all-Debug/bin/opt(_ZN4llvm6legacy15PassManagerImpl3runERNS_6ModuleE+0x125)[0x37d3a65]
build-all-Debug/bin/opt(_ZN4llvm6legacy11PassManager3runERNS_6ModuleE+0x21)[0x37d8b61]
build-all-Debug/bin/opt(main+0x34f9)[0xde3279]
/lib64/libc.so.6(__libc_start_main+0xf5)[0x7f889aebc555]
build-all-Debug/bin/opt[0xda7f74]
Segmentation fault
If I go up a couple of stack frames in the debugger we see
#7 0x0000000002be275b in llvm::LoopInfoBase<llvm::BasicBlock,
llvm::Loop>::analyze (this=0x7fffffffb398, DomTree=...) at
../include/llvm/Analysis/LoopInfoImpl.h:548
548 for (auto DomNode : post_order(DomRoot)) {
(gdb) p DomRoot
$5 = (const llvm::DomTreeNodeBase<llvm::BasicBlock> *) 0x0
So I guess the DomTree used to verify LoopInfo isn't really good
#9 0x0000000002bdae88 in llvm::LoopInfoWrapperPass::verifyAnalysis
(this=0x8fc9b40) at ../lib/Analysis/LoopInfo.cpp:1114
1114 LI.verify(DT);
(gdb) p DT
$6 = (llvm::DominatorTree &) @0x8fc9930:
{<llvm::DominatorTreeBase<llvm::BasicBlock, false>> = {static IsPostDominator =
false, static Insert = llvm::cfg::Insert,
static Delete = llvm::cfg::Delete,
Roots = {<llvm::SmallVectorImpl<llvm::BasicBlock*>> =
{<llvm::SmallVectorTemplateBase<llvm::BasicBlock*, true>> =
{<llvm::SmallVectorTemplateCommon<llvm::BasicBlock*, void>> =
{<llvm::SmallVectorBase<unsigned int>> = {BeginX = 0x8fc9940, Size = 0,
Capacity = 1}, <No data fields>},
static TakesParamByValue = true}, <No data fields>},
<llvm::SmallVectorStorage<llvm::BasicBlock*, 1>> = {InlineElts =
"ะบ\374\b\000\000\000"}, <No data fields>},
DomTreeNodes = {<llvm::DenseMapBase<llvm::DenseMap<llvm::BasicBlock*,
std::unique_ptr<llvm::DomTreeNodeBase<llvm::BasicBlock>,
std::default_delete<llvm::DomTreeNodeBase<llvm::BasicBlock> > >,
llvm::DenseMapInfo<llvm::BasicBlock*>,
llvm::detail::DenseMapPair<llvm::BasicBlock*,
std::unique_ptr<llvm::DomTreeNodeBase<llvm::BasicBlock>,
std::default_delete<llvm::DomTreeNodeBase<llvm::BasicBlock> > > > >,
llvm::BasicBlock*, std::unique_ptr<llvm::DomTreeNodeBase<llvm::BasicBlock>,
std::default_delete<llvm::DomTreeNodeBase<llvm::BasicBlock> > >,
llvm::DenseMapInfo<llvm::BasicBlock*>,
llvm::detail::DenseMapPair<llvm::BasicBlock*,
std::unique_ptr<llvm::DomTreeNodeBase<llvm::BasicBlock>,
std::default_delete<llvm::DomTreeNodeBase<llvm::BasicBlock> > > > >> =
{<llvm::DebugEpochBase> = {Epoch = 3}, <No data fields>}, Buckets = 0x8fd1640,
NumEntries = 0, NumTombstones = 0, NumBuckets = 64}, RootNode = 0x0, Parent =
0x0, DFSInfoValid = false,
SlowQueries = 0}, <No data fields>}
This starts happening with 66c120f02560:
[VectorUtils] Rework the Vector Function Database (VFDatabase).
Summary:
This commits is a rework of the patch in
https://reviews.llvm.org/D67572.
The rework was requested to prevent out-of-tree performance regression
when vectorizing out-of-tree IR intrinsics. The vectorization of such
intrinsics is enquired via the static function `isTLIScalarize`. For
detail see the discussion in https://reviews.llvm.org/D67572.
Reviewers: uabelho, fhahn, sdesmalen
Subscribers: hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D72734
--
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/20210413/65fba367/attachment-0001.html>
More information about the llvm-bugs
mailing list