Open matoro opened 2 years ago
Looks like the optimizations aren't the issue here.
The problem is that there's a stack overflow when trying to write out bitcode. So just doing opt ghc_4.ll -o foo.bc
also fails with:
...
#244 0x10d3ea089 in predictValueUseListOrder(llvm::Value const*, llvm::Function const*, (anonymous namespace)::OrderMap&, std::__1::vector<llvm::UseListOrder, std::__1::allocator<llvm::UseListOrder> >&) ValueEnumerator.cpp:241
#245 0x10d3ea089 in predictValueUseListOrder(llvm::Value const*, llvm::Function const*, (anonymous namespace)::OrderMap&, std::__1::vector<llvm::UseListOrder, std::__1::allocator<llvm::UseListOrder> >&) ValueEnumerator.cpp:241
#246 0x10d3ea089 in predictValueUseListOrder(llvm::Value const*, llvm::Function const*, (anonymous namespace)::OrderMap&, std::__1::vector<llvm::UseListOrder, std::__1::allocator<llvm::UseListOrder> >&) ValueEnumerator.cpp:241
#247 0x10d3ea089 in predictValueUseListOrder(llvm::Value const*, llvm::Function const*, (anonymous namespace)::OrderMap&, std::__1::vector<llvm::UseListOrder, std::__1::allocator<llvm::UseListOrder> >&) ValueEnumerator.cpp:241
#248 0x10d3ea089 in predictValueUseListOrder(llvm::Value const*, llvm::Function const*, (anonymous namespace)::OrderMap&, std::__1::vector<llvm::UseListOrder, std::__1::allocator<llvm::UseListOrder> >&) ValueEnumerator.cpp:241
#249 0x10d3ea089 in predictValueUseListOrder(llvm::Value const*, llvm::Function const*, (anonymous namespace)::OrderMap&, std::__1::vector<llvm::UseListOrder, std::__1::allocator<llvm::UseListOrder> >&) ValueEnumerator.cpp:241
#250 0x10d3ea089 in predictValueUseListOrder(llvm::Value const*, llvm::Function const*, (anonymous namespace)::OrderMap&, std::__1::vector<llvm::UseListOrder, std::__1::allocator<llvm::UseListOrder> >&) ValueEnumerator.cpp:241
#251 0x10d3ea089 in predictValueUseListOrder(llvm::Value const*, llvm::Function const*, (anonymous namespace)::OrderMap&, std::__1::vector<llvm::UseListOrder, std::__1::allocator<llvm::UseListOrder> >&) ValueEnumerator.cpp:241
#252 0x10d3ea089 in predictValueUseListOrder(llvm::Value const*, llvm::Function const*, (anonymous namespace)::OrderMap&, std::__1::vector<llvm::UseListOrder, std::__1::allocator<llvm::UseListOrder> >&) ValueEnumerator.cpp:241
#253 0x10d3ea089 in predictValueUseListOrder(llvm::Value const*, llvm::Function const*, (anonymous namespace)::OrderMap&, std::__1::vector<llvm::UseListOrder, std::__1::allocator<llvm::UseListOrder> >&) ValueEnumerator.cpp:241
#254 0x10d3ea089 in predictValueUseListOrder(llvm::Value const*, llvm::Function const*, (anonymous namespace)::OrderMap&, std::__1::vector<llvm::UseListOrder, std::__1::allocator<llvm::UseListOrder> >&) ValueEnumerator.cpp:241
#255 0x10d3ea089 in predictValueUseListOrder(llvm::Value const*, llvm::Function const*, (anonymous namespace)::OrderMap&, std::__1::vector<llvm::UseListOrder, std::__1::allocator<llvm::UseListOrder> >&) ValueEnumerator.cpp:241
or even simpler: llvm-as ghc_4.ll
Compiling the following Haskell from the Happy test suite using GHC 9.0.2: issue93.a.hs.gz
using the command line:
ghc -fllvm -Wall -Werror -fforce-recomp issue93.a.hs -o issue93.a.bin
generates the following IR: ghc_4.ll.gz
GHC then invokes
opt
, with the following command line:opt -mem2reg -globalopt -lower-expect -enable-tbaa -tbaa -relocation-model=pic ghc_4.ll -o ghc_6.bc
which crashes when processing the IR with the following traceback: 3TTJHXQYK.txt
Tested using
opt
from LLVM 13.0.1, 14.0.6, and git master, on amd64, arm64, and ppc64le. Same traceback on all versions and arches. The specific traceback above is from git master. Fully reproducible from what I can tell.I tried to minimize the IR, first using
bugpoint
. Unfortunatelybugpoint
itself segfaults, with the exact same traceback asopt
. I then tried usingllvm-reduce
, but it also segfaults after three passes, and the slightly reduced IR it leaves behind is not valid, and can't be processed byopt
.