| Issue |
166653
|
| Summary |
Bugpoint's ReduceCrashingInstructions strategy is incompatible with Intel AMX
|
| Labels |
new issue
|
| Assignees |
|
| Reporter |
thurstond
|
Consider this test case:
```
; Modified from llvm/test/CodeGen/X86/AMX/amx-ldtilecfg-insert.ll
@buf = dso_local global [3072 x i8] zeroinitializer, align 16
define dso_local void @test1(i16 signext %0, i16 signext %1) {
; i16 poison is not valid
%3 = tail call x86_amx @llvm.x86.tileloadd64.internal(i16 poison, i16 8, ptr @buf, i64 32)
%6 = tail call x86_amx @llvm.x86.tdpbssd.internal(i16 %0, i16 %1, i16 8, x86_amx %3, x86_amx %3, x86_amx %3)
ret void
}
declare x86_amx @llvm.x86.tileloadd64.internal(i16, i16, ptr, i64)
declare x86_amx @llvm.x86.tdpbssd.internal(i16, i16, i16, x86_amx, x86_amx, x86_amx)
```
which passes the LLVM verifier, but crashes `llc` (`LLVM ERROR: Cannot select: intrinsic %llvm.x86.tdpbssd.internal`). Here, the test case is already (manually) reduced and the error is simple enough.
But suppose I have a similar bug as part of a larger testcase, and I use bugpoint to reduce it:
```
bin/bugpoint --run-llc foo.ll
```
One of its strategies is:
```
/// ReduceCrashingInstructions reducer - This works by removing the specified
/// non-terminator instructions and replacing them with undef.
```
It ends up rewriting the valid call:
```
...
%3 = tail call x86_amx @llvm.x86.tdpbssd.internal(i16 %0, i16 %1, i16 8, x86_amx %3, x86_amx %3, x86_amx %3)
```
into an invalid call:
```
%3 = tail call x86_amx @llvm.x86.tdpbssd.internal(i16 %0, i16 %1, i16 8, x86_amx poison, x86_amx poison, x86_amx poison)
```
which then crashes:
```
*** Attempting to reduce testcase by deleting instructions: Simplification Level #1
Checking instruction: %3 = tail call x86_amx @llvm.x86.tdpbssd.internal(i16 %0, i16 %1, i16 8, x86_amx poison, x86_amx poison, x86_amx poison)Cannot create a null constant of that type!
UNREACHABLE executed at /usr/local/google/home/thurston/llvm-projectF/llvm/lib/IR/Constants.cpp:399!
PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace and instructions to reproduce the bug.
Stack dump:
0. Program arguments: bin/bugpoint --run-llc /tmp/q.ll
#0 0x00005585cbf0c611 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) /usr/local/google/home/thurston/llvm-projectF/llvm/lib/Support/Unix/Signals.inc:834:11
#1 0x00005585cbf0cb8b PrintStackTraceSignalHandler(void*) /usr/local/google/home/thurston/llvm-projectF/llvm/lib/Support/Unix/Signals.inc:916:1
#2 0x00005585cbf0a8a6 llvm::sys::RunSignalHandlers() /usr/local/google/home/thurston/llvm-projectF/llvm/lib/Support/Signals.cpp:104:5
#3 0x00005585cbf0d30d SignalHandler(int, siginfo_t*, void*) /usr/local/google/home/thurston/llvm-projectF/llvm/lib/Support/Unix/Signals.inc:426:38
#4 0x00007fd99b049df0 (/lib/x86_64-linux-gnu/libc.so.6+0x3fdf0)
#5 0x00007fd99b09e95c __pthread_kill_implementation ./nptl/pthread_kill.c:44:76
#6 0x00007fd99b049cc2 raise ./signal/../sysdeps/posix/raise.c:27:6
#7 0x00007fd99b0324ac abort ./stdlib/abort.c:81:3
#8 0x00005585cbe289d0 llvm::install_out_of_memory_new_handler() /usr/local/google/home/thurston/llvm-projectF/llvm/lib/Support/ErrorHandling.cpp:225:0
#9 0x00005585cb4ed66b llvm::Constant::getNullValue(llvm::Type*) /usr/local/google/home/thurston/llvm-projectF/llvm/lib/IR/Constants.cpp:401:1
#10 0x00005585c7a3c116 llvm::BugDriver::deleteInstructionFromProgram(llvm::Instruction const*, unsigned int) /usr/local/google/home/thurston/llvm-projectF/llvm/tools/bugpoint/ExtractFunction.cpp:104:33
#11 0x00005585c79f12d6 ReduceInsts(llvm::BugDriver&, bool (*)(llvm::BugDriver const&, llvm::Module*)) /usr/local/google/home/thurston/llvm-projectF/llvm/tools/bugpoint/CrashDebugger.cpp:1135:19
#12 0x00005585c79efa5f DebugACrash(llvm::BugDriver&, bool (*)(llvm::BugDriver const&, llvm::Module*)) /usr/local/google/home/thurston/llvm-projectF/llvm/tools/bugpoint/CrashDebugger.cpp:1286:19
#13 0x00005585c79f034b llvm::BugDriver::debugCodeGeneratorCrash() /usr/local/google/home/thurston/llvm-projectF/llvm/tools/bugpoint/CrashDebugger.cpp:1411:10
#14 0x00005585c79e808f llvm::BugDriver::run() /usr/local/google/home/thurston/llvm-projectF/llvm/tools/bugpoint/BugDriver.cpp:185:12
#15 0x00005585c7a649dd main /usr/local/google/home/thurston/llvm-projectF/llvm/tools/bugpoint/bugpoint.cpp:176:13
#16 0x00007fd99b033ca8 __libc_start_call_main ./csu/../sysdeps/nptl/libc_start_call_main.h:74:3
#17 0x00007fd99b033d65 call_init ./csu/../csu/libc-start.c:128:20
#18 0x00007fd99b033d65 __libc_start_main ./csu/../csu/libc-start.c:347:5
#19 0x00005585c79e72a1 _start (bin/bugpoint+0xf0b2a1)
Aborted
```
In my experience, with larger test cases, bugpoint's `ReduceCrashingInstructions` frequently synthesizes `x86_amx poison`, making it impossible to identify the real bug.
----
N.B. llvm/tools/bugpoint/CrashDebugger.cpp does call:
```
isValidModule(M, /*ExitOnFailure=*/false);
```
but AFAICS it's purely informational - it doesn't reject the reduction if it creates invalid IR.
![]()
_______________________________________________
llvm-bugs mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
