opt: Instruction Combining did not reach a fixpoint after 1 iterations

[aykevl]

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

[dtcxzyw]

opt-18 -o crash.out.bc -passes='instcombine<no-verify-fixpoint>' reduced.ll should work.

To disable this assertion, you should set InstCombineOptions.VerifyFixpoint to false 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]

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 just instcombine in the C API.

[dtcxzyw]

Can I close this issue?

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 instead of just instcombine in the C API.

Do you think it is better to turn it off by default? cc @nikic

[aykevl]

Can I close this issue?

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".