clspv crashes in SimplifyPointerBitcastPass runOnGEPFromGEP #1561
Description
Hello clspv devs,
I've come across a crash in clspv that occurs in the SimplifyPointerBitcastPass.cpp::runOnGEPFromGEP function using commit 75d2471.
Here is a small IR program (distilled from a more complex kernel) which triggers the crash when run with clspv-opt <file> --passes=simplify-pointer-bitcast.
target datalayout = "e-p:32:32-i64:64-v16:16-v24:32-v32:32-v48:64-v96:128-v192:256-v256:256-v512:512-v1024:1024"
target triple = "spir-unknown-unknown"
define dso_local spir_kernel void @spir_kernel(ptr addrspace(1) align 8 %dest) {
entry:
br label %label0
label1:
%idx0 = getelementptr i8, ptr addrspace(1) %idx2, i32 0
br label %label2
label0:
%idx1 = getelementptr i8, ptr addrspace(1) %dest, i32 0
%idx2 = getelementptr i8, ptr addrspace(1) %idx1, i32 0
br label %label1
label2:
%idx3 = getelementptr i8, ptr addrspace(1) %idx0, i32 0
store i32 0, ptr addrspace(1) %idx3, align 8
ret void
}
Stack dump:
0. Program arguments: clspv-opt ./gep-chain-simplify-test.ll -o out.asm --passes=simplify-pointer-bitcast
1. Running pass "simplify-pointer-bitcast" on module "./gep-chain-simplify-test.ll"
#0 0x000055ce63887bdd llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) /home/shaun/clspv/third_party/llvm/llvm/lib/Support/Unix/Signals.inc:842:11
#1 0x000055ce6388813b PrintStackTraceSignalHandler(void*) /home/shaun/clspv/third_party/llvm/llvm/lib/Support/Unix/Signals.inc:924:1
#2 0x000055ce63885e6b llvm::sys::RunSignalHandlers() /home/shaun/clspv/third_party/llvm/llvm/lib/Support/Signals.cpp:108:5
#3 0x000055ce638888ad SignalHandler(int, siginfo_t*, void*) /home/shaun/clspv/third_party/llvm/llvm/lib/Support/Unix/Signals.inc:429:38
#4 0x00007fa197154420 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x14420)
#5 0x00007fa196c4300b raise /build/glibc-B3wQXB/glibc-2.31/signal/../sysdeps/unix/sysv/linux/raise.c:51:1
#6 0x00007fa196c22859 abort /build/glibc-B3wQXB/glibc-2.31/stdlib/abort.c:81:7
#7 0x00007fa196c22729 get_sysdep_segment_value /build/glibc-B3wQXB/glibc-2.31/intl/loadmsgcat.c:509:8
#8 0x00007fa196c22729 _nl_load_domain /build/glibc-B3wQXB/glibc-2.31/intl/loadmsgcat.c:970:34
#9 0x00007fa196c33fd6 (/lib/x86_64-linux-gnu/libc.so.6+0x33fd6)
#10 0x000055ce6290ea58 decltype(auto) llvm::cast<llvm::GetElementPtrInst, llvm::Value>(llvm::Value*) /home/shaun/clspv/third_party/llvm/llvm/include/llvm/Support/Casting.h:573:10
#11 0x000055ce6290b4c1 clspv::SimplifyPointerBitcastPass::runOnGEPFromGEP(llvm::Module&) const /home/shaun/clspv/lib/SimplifyPointerBitcastPass.cpp:238:10
#12 0x000055ce62905b84 clspv::SimplifyPointerBitcastPass::run(llvm::Module&, llvm::AnalysisManager<llvm::Module>&) /home/shaun/clspv/lib/SimplifyPointerBitcastPass.cpp:59:16
#13 0x000055ce62836014 llvm::detail::PassModel<llvm::Module, clspv::SimplifyPointerBitcastPass, llvm::AnalysisManager<llvm::Module>>::run(llvm::Module&, llvm::AnalysisManager<llvm::Module>&) /home/shaun/clspv/third_party/llvm/llvm/include/llvm/IR/PassManagerInternal.h:91:17
#14 0x000055ce6303453a llvm::PassManager<llvm::Module, llvm::AnalysisManager<llvm::Module>>::run(llvm::Module&, llvm::AnalysisManager<llvm::Module>&) /home/shaun/clspv/third_party/llvm/llvm/include/llvm/IR/PassManagerImpl.h:80:5
#15 0x000055ce6273b206 main /home/shaun/clspv/tools/clspv-opt/main.cpp:126:3
#16 0x00007fa196c24083 __libc_start_main /build/glibc-B3wQXB/glibc-2.31/csu/../csu/libc-start.c:342:3
#17 0x000055ce6273aa3e _start (clspv-opt+0x1a1a3e)
Aborted (core dumped)
From what I can make out the issue is closely related to the ordering of the chained GEP instructions in the IR program. It appears that in certain cases the work list processing loop in runOnGEPFromGEP erases instructions from the basic block which have still yet to be processed, resulting in access to a invalid pointer.
I was able to workaround this crash by adding the candidate GEP instructions to a set and deferring their removal until after the processing loop completes - not sure if this is the correct fix but noted some of the other transformations in this pass also follow this pattern.
Thanks,
Shaun