[llvm] [InstCombine] Replace all dominated uses of condition with constants (PR #105510)

Mikael Holmén via llvm-commits llvm-commits at lists.llvm.org
Fri Oct 25 04:16:16 PDT 2024


mikaelholmen wrote:

Hi @dtcxzyw

I've bisected a problem back to this patch.
With
```opt -passes='instcombine' bbi_100446_2.ll -o /dev/null```
we hit
```
opt: ../include/llvm/Support/GenericDomTree.h:401: DomTreeNodeBase<NodeT> *llvm::DominatorTreeBase<llvm::BasicBlock, false>::getNode(const NodeT *) const [NodeT = llvm::BasicBlock, IsPostDom = false]: Assertion `(!BB || Parent == NodeTrait::getParent(const_cast<NodeT *>(BB))) && "cannot get DomTreeNode of block with different parent"' failed.
PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace.
Stack dump:
0.	Program arguments: build-all/bin/opt -passes=instcombine bbi_100446_2.ll -o /dev/null
1.	Running pass "function(instcombine<max-iterations=1;verify-fixpoint>)" on module "bbi_100446_2.ll"
2.	Running pass "instcombine<max-iterations=1;verify-fixpoint>" on function "fn2"
 #0 0x0000558ac6150ad8 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (build-all/bin/opt+0x43bcad8)
 #1 0x0000558ac614e59e llvm::sys::RunSignalHandlers() (build-all/bin/opt+0x43ba59e)
 #2 0x0000558ac615130d SignalHandler(int) Signals.cpp:0:0
 #3 0x00007f986b3c3cf0 __restore_rt (/lib64/libpthread.so.0+0x12cf0)
 #4 0x00007f9868f7cacf raise (/lib64/libc.so.6+0x4eacf)
 #5 0x00007f9868f4fea5 abort (/lib64/libc.so.6+0x21ea5)
 #6 0x00007f9868f4fd79 _nl_load_domain.cold.0 (/lib64/libc.so.6+0x21d79)
 #7 0x00007f9868f75426 (/lib64/libc.so.6+0x47426)
 #8 0x0000558ac674d7b0 llvm::DominatorTreeBase<llvm::BasicBlock, false>::dominates(llvm::BasicBlock const*, llvm::BasicBlock const*) const (build-all/bin/opt+0x49b97b0)
 #9 0x0000558ac6757e3d llvm::DominatorTree::dominates(llvm::BasicBlockEdge const&, llvm::BasicBlock const*) const (build-all/bin/opt+0x49c3e3d)
#10 0x0000558ac6d9c69a llvm::InstCombinerImpl::visitBranchInst(llvm::BranchInst&) InstructionCombining.cpp:0:0
#11 0x0000558ac6da407a llvm::InstCombinerImpl::run() InstructionCombining.cpp:0:0
#12 0x0000558ac6da76c2 combineInstructionsOverFunction(llvm::Function&, llvm::InstructionWorklist&, llvm::AAResults*, llvm::AssumptionCache&, llvm::TargetLibraryInfo&, llvm::TargetTransformInfo&, llvm::DominatorTree&, llvm::OptimizationRemarkEmitter&, llvm::BlockFrequencyInfo*, llvm::BranchProbabilityInfo*, llvm::ProfileSummaryInfo*, llvm::InstCombineOptions const&) InstructionCombining.cpp:0:0
#13 0x0000558ac6da6c1d llvm::InstCombinePass::run(llvm::Function&, llvm::AnalysisManager<llvm::Function>&) (build-all/bin/opt+0x5012c1d)
#14 0x0000558ac74edffd llvm::detail::PassModel<llvm::Function, llvm::InstCombinePass, llvm::AnalysisManager<llvm::Function>>::run(llvm::Function&, llvm::AnalysisManager<llvm::Function>&) PassBuilderPipelines.cpp:0:0
#15 0x0000558ac63572a7 llvm::PassManager<llvm::Function, llvm::AnalysisManager<llvm::Function>>::run(llvm::Function&, llvm::AnalysisManager<llvm::Function>&) (build-all/bin/opt+0x45c32a7)
#16 0x0000558ac74f3d3d llvm::detail::PassModel<llvm::Function, llvm::PassManager<llvm::Function, llvm::AnalysisManager<llvm::Function>>, llvm::AnalysisManager<llvm::Function>>::run(llvm::Function&, llvm::AnalysisManager<llvm::Function>&) PassBuilderPipelines.cpp:0:0
#17 0x0000558ac635be36 llvm::ModuleToFunctionPassAdaptor::run(llvm::Module&, llvm::AnalysisManager<llvm::Module>&) (build-all/bin/opt+0x45c7e36)
#18 0x0000558ac74ed7dd llvm::detail::PassModel<llvm::Module, llvm::ModuleToFunctionPassAdaptor, llvm::AnalysisManager<llvm::Module>>::run(llvm::Module&, llvm::AnalysisManager<llvm::Module>&) PassBuilderPipelines.cpp:0:0
#19 0x0000558ac6355fd7 llvm::PassManager<llvm::Module, llvm::AnalysisManager<llvm::Module>>::run(llvm::Module&, llvm::AnalysisManager<llvm::Module>&) (build-all/bin/opt+0x45c1fd7)
#20 0x0000558ac74921b3 llvm::runPassPipeline(llvm::StringRef, llvm::Module&, llvm::TargetMachine*, llvm::TargetLibraryInfoImpl*, llvm::ToolOutputFile*, llvm::ToolOutputFile*, llvm::ToolOutputFile*, llvm::StringRef, llvm::ArrayRef<llvm::PassPlugin>, llvm::ArrayRef<std::function<void (llvm::PassBuilder&)>>, llvm::opt_tool::OutputKind, llvm::opt_tool::VerifierKind, bool, bool, bool, bool, bool, bool, bool) (build-all/bin/opt+0x56fe1b3)
#21 0x0000558ac6117ecb optMain (build-all/bin/opt+0x4383ecb)
#22 0x00007f9868f68d85 __libc_start_main (/lib64/libc.so.6+0x3ad85)
#23 0x0000558ac6111cee _start (build-all/bin/opt+0x437dcee)
Abort (core dumped)
```
It's very weird, when we iterate over the uses of the condition
```ptrtoint (ptr addrspace(21) @g to i1)```
in the branch in fn2 we first find the branch instruction itself in fn2 that we're visiting
```br i1 ptrtoint (ptr addrspace(21) @g to i1), label %scalar.ph, label %vector.ph```
but then we _also_ find the identical branch
```br i1 ptrtoint (ptr addrspace(21) @g to i1), label %scalar.ph, label %vector.ph```
in fn1!
Then DT asserts because it detects something funny is going on.

[bbi_100446_2.ll.gz](https://github.com/user-attachments/files/17521126/bbi_100446_2.ll.gz)


https://github.com/llvm/llvm-project/pull/105510


More information about the llvm-commits mailing list