Open
Description
opt-18
crashes with the following input:
target datalayout = "e-m:e-i8:8:32-i16:16:32-i64:64-i128:128-n32:64-S128"
target triple = "aarch64-unknown-linux"
@global = global i8 0, align 1
define i32 @testcase() {
entry:
%0 = load i8, ptr @global
%1 = zext i8 %0 to i32
%2 = icmp slt i32 %1, 128
br i1 %2, label %if.then, label %if.done
if.then:
ret i32 %1
if.done:
ret i32 0
}
This is a heavily reduced test case that I hit when updating my compiler to LLVM 18 (thanks to llvm-reduce, because bugpoint couldn't reduce my testcase).
Result:
$ opt-18 -o crash.out.bc -passes instcombine reduced.ll
LLVM ERROR: Instruction Combining did not reach a fixpoint after 1 iterations
PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace.
Stack dump:
0. Program arguments: opt-18 -o crash.out.bc -passes instcombine reduced.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):
0 libLLVM.so.18.1 0x0000ffff88d91518 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) + 80
1 libLLVM.so.18.1 0x0000ffff88d8f7c0 llvm::sys::RunSignalHandlers() + 112
2 libLLVM.so.18.1 0x0000ffff88d91c28
3 linux-vdso.so.1 0x0000ffff8fe2c800 __kernel_rt_sigreturn + 0
4 libc.so.6 0x0000ffff8fa90a10
5 libc.so.6 0x0000ffff8fa4a76c gsignal + 28
6 libc.so.6 0x0000ffff8fa374bc abort + 240
7 libLLVM.so.18.1 0x0000ffff88cedd54 llvm::report_fatal_error(llvm::Twine const&, bool) + 432
8 libLLVM.so.18.1 0x0000ffff899ecba0
9 libLLVM.so.18.1 0x0000ffff899ec5e0 llvm::InstCombinePass::run(llvm::Function&, llvm::AnalysisManager<llvm::Function>&) + 552
10 libLLVM.so.18.1 0x0000ffff88f0bce0 llvm::PassManager<llvm::Function, llvm::AnalysisManager<llvm::Function>>::run(llvm::Function&, llvm::AnalysisManager<llvm::Function>&) + 240
11 libLLVM.so.18.1 0x0000ffff88f0f2a4 llvm::ModuleToFunctionPassAdaptor::run(llvm::Module&, llvm::AnalysisManager<llvm::Module>&) + 324
12 libLLVM.so.18.1 0x0000ffff88f0abc8 llvm::PassManager<llvm::Module, llvm::AnalysisManager<llvm::Module>>::run(llvm::Module&, llvm::AnalysisManager<llvm::Module>&) + 328
13 opt-18 0x0000aaaabe25d158 llvm::runPassPipeline(llvm::StringRef, llvm::Module&, llvm::TargetMachine*, llvm::TargetLibraryInfoImpl*, llvm::ToolOutputFile*, llvm::ToolOutputFile*, llvm::ToolOutputFile*, llvm::StringRef, llvm::ArrayRef<llvm::PassPlugin>, llvm::opt_tool::OutputKind, llvm::opt_tool::VerifierKind, bool, bool, bool, bool, bool, bool, bool) + 11264
14 opt-18 0x0000aaaabe269fcc main + 6808
15 libc.so.6 0x0000ffff8fa37780
16 libc.so.6 0x0000ffff8fa37858 __libc_start_main + 152
17 opt-18 0x0000aaaabe2579b0 _start + 48
Version:
$ opt-18 --version
Debian LLVM version 18.1.6
Optimized build.
Default target: aarch64-unknown-linux-gnu
Host CPU: (unknown)
Environment: Debian 12 running inside a distrobox (host OS is Fedora Asahi 39).
EDIT: still happening on trunk: https://llvm.godbolt.org/z/8eh88z17a
Metadata
Metadata
Assignees
Type
Projects
Milestone
Relationships
Development
No branches or pull requests
Activity
dtcxzyw commentedon May 19, 2024
opt-18 -o crash.out.bc -passes='instcombine<no-verify-fixpoint>' reduced.ll
should work.To disable this assertion, you should set
InstCombineOptions.VerifyFixpoint
tofalse
when constructing InstCombinePass.For more details about single-iteration InstCombine and fixpoints, see @nikic's blog: https://www.npopov.com/2024/01/01/This-year-in-LLVM-2023.html#compile-time-improvements and https://developers.redhat.com/articles/2023/12/07/how-single-iteration-instcombine-improves-llvm-compile-time.
aykevl commentedon May 19, 2024
I discovered there was a switch for this after reporting this as a bug (and apparently the intention is that compiler developers set this to "off" even though the default is "on"). I fixed it as you described, by using
instcombine<no-verify-fixpoint>
instead of justinstcombine
in the C API.dtcxzyw commentedon May 19, 2024
Can I close this issue?
Do you think it is better to turn it off by default? cc @nikic
aykevl commentedon May 20, 2024
Sure, if this is the intended behavior.
I think it's on by default so that tests run with it on by default in
opt
. But it's weird that it's also on by default in the C API. Perhaps a better error message would help? Something like "Instruction Combining did not reach a fixpoint after 1 iterations, turn this off using the no-verify-fixpoint flag in production builds".