ICE on ridiculous int

[jeremy-rifkin]

Bugzilla Link	51829
Resolution	FIXED
Resolved on	Sep 14, 2021 08:12
Version	trunk
OS	Windows NT
CC	@topperc,@erichkeane,@RKSimon
Fixed by commit(s)	2fd180b

Extended Description

The following code causes an ICE:

define void @​foo(i16777215* %0, i16777215* %1, i16777215* %2) {
%4 = load i16777215, i16777215* %1
%5 = load i16777215, i16777215* %2
%6 = add nsw i16777215 %5, %4
store i16777215 %6, i16777215* %0
ret void
}

or C++:
typedef _ExtInt(16777215) i;
i foo(i a, i b) {
return a + b;
}

PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash backtrace.
Stack dump:
0. Program arguments: /opt/compiler-explorer/clang-trunk/bin/llc -o /app/output.s -x86-asm-syntax=intel

1. Running pass 'Function Pass Manager' on module ''.
2. Running pass 'X86 DAG->DAG Instruction Selection' on function '@foo'
   #​0 0x000055ade6ed25bf PrintStackTraceSignalHandler(void*) Signals.cpp:0:0
   #​1 0x000055ade6ecfe6d SignalHandler(int) Signals.cpp:0:0
   #​2 0x00007f915f8a43c0 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x153c0)
   #​3 0x000055ade6e0493a llvm::APInt::setBitsSlowCase(unsigned int, unsigned int) (/opt/compiler-explorer/clang-trunk/bin/llc+0x2a0493a)
   #​4 0x000055ade5385aac llvm::APInt::getLowBitsSet(unsigned int, unsigned int) (/opt/compiler-explorer/clang-trunk/bin/llc+0xf85aac)
   #​5 0x000055ade6bffea6 (anonymous namespace)::DAGCombiner::visitSTORE(llvm::SDNode*) DAGCombiner.cpp:0:0
   #​6 0x000055ade6c09269 (anonymous namespace)::DAGCombiner::visit(llvm::SDNode*) DAGCombiner.cpp:0:0
   #​7 0x000055ade6c0bccd (anonymous namespace)::DAGCombiner::combine(llvm::SDNode*) DAGCombiner.cpp:0:0
   #​8 0x000055ade6c0d5ac llvm::SelectionDAG::Combine(llvm::CombineLevel, llvm::AAResults*, llvm::CodeGenOpt::Level) (/opt/compiler-explorer/clang-trunk/bin/llc+0x280d5ac)
   #​9 0x000055ade6d06db7 llvm::SelectionDAGISel::CodeGenAndEmitDAG() (/opt/compiler-explorer/clang-trunk/bin/llc+0x2906db7)
   #​10 0x000055ade6d0a104 llvm::SelectionDAGISel::SelectAllBasicBlocks(llvm::Function const&) (/opt/compiler-explorer/clang-trunk/bin/llc+0x290a104)
   #​11 0x000055ade6d0c392 llvm::SelectionDAGISel::runOnMachineFunction(llvm::MachineFunction&) (.part.887) SelectionDAGISel.cpp:0:0
   #​12 0x000055ade5ab8fd0 (anonymous namespace)::X86DAGToDAGISel::runOnMachineFunction(llvm::MachineFunction&) X86ISelDAGToDAG.cpp:0:0
   #​13 0x000055ade6332458 llvm::MachineFunctionPass::runOnFunction(llvm::Function&) (/opt/compiler-explorer/clang-trunk/bin/llc+0x1f32458)
   #​14 0x000055ade6758fb9 llvm::FPPassManager::runOnFunction(llvm::Function&) (/opt/compiler-explorer/clang-trunk/bin/llc+0x2358fb9)
   #​15 0x000055ade6759251 llvm::FPPassManager::runOnModule(llvm::Module&) (/opt/compiler-explorer/clang-trunk/bin/llc+0x2359251)
   #​16 0x000055ade675a4c7 llvm::legacy::PassManagerImpl::run(llvm::Module&) (/opt/compiler-explorer/clang-trunk/bin/llc+0x235a4c7)
   #​17 0x000055ade4cd6da1 compileModule(char**, llvm::LLVMContext&) llc.cpp:0:0
   #​18 0x000055ade4c02c56 main (/opt/compiler-explorer/clang-trunk/bin/llc+0x802c56)
   #​19 0x00007f915f3540b3 __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x270b3)
   #​20 0x000055ade4cceb1a _start (/opt/compiler-explorer/clang-trunk/bin/llc+0x8ceb1a)
   Compiler returned: 139

Needless to say, ICE on this core feature is breaking many codebases and should have top priority :)

Bug goes at least back to 10.0.0.

[jeremy-rifkin]

ICE might be specifically because of the loads/store. The code below may be fine but, though I've been waiting an hour and a half and llc is still chugging away on it.

define i16777215 @​foo(i16777215 %0, i16777215 %1) {
%3 = add nsw i16777215 %0, %1
ret i16777215 %3
}

[topperc]

I think bad things are happening much earlier than the crash. SelectionDAG needs to increase the size of the type to a power of 2 before splitting it into register sized pieces. This requires an i16777216 to be created, but llvm can't have integers that require more than 24 bits for the bitwidth.

The easiest fix is to limit ExtInt to 2^23 or fewer bits.

[erichkeane]

The easiest fix is to limit ExtInt to 2^23 or fewer bits.

_ExtInt/_BitInt are limited to the llvm::IntegerType::MAX_INT_BITS. My understanding was that llvm was supposed to support integers up to that size, right?

I guess we could change our implementation-defined size, but this seems like an issue with LLVM not suppporting its published limits.

[topperc]

I don't know an easy way to fix it without big changes to SelectionDAG. The generic type legalization strategy is to round the type up to the next power of 2 by adding shl+ashr or ands to the inputs as needed to keep operations legal on the wider type. Then divide every operation in half over and over again until we get down to a legal size. This division assumes that the type can be perfectly divided by 2 repeatedly.

I'm concerned that there might be a different crash if the splits produce more than 65535 pieces due to another size restriction. The compile time for really large integers is bad so I haven't confirmed that yet.

Looks like LangRef says 2^23-1 (~8 million) because llvm::IntegerType::MAX_INT_BITS used to be 23 and no one updated it.

[erichkeane]

Do we know when that was changed? It would be great if we didn't end up having this be a breaking change between releases.

[topperc]

This should be an error at compile time after 2fd180b