Failure Details:
eval_ir_main times out when executing the IR via LLVM JIT (--use_llvm_jit).
Reproduction:
/google/bin/releases/xls/eval_ir_main \
--testvector_textproto=testvector.pbtxt \
--use_llvm_jit \
sample.ir \
--logtostderr
(Using files extracted from crasher_2026-05-23_85e7.x)
Root Cause:
The top function has a complex return type containing a large array of tuples:
-> (bits[1], (bits[1], bits[1], bits[1], bits[1])[1818])
Even when the IR is minimized to simply return a literal of this type:
top fn __sample__main(...) -> (bits[1], (bits[1], bits[1], bits[1], bits[1])[1818]) {
ret literal.14276: ... = literal(...)
}
LLVM JIT (eval_ir_main) still hangs/timeouts even with a single input vector.
This suggests the issue is in how LLVM or the XLS LLVM JIT bridge handles extremely large or complex return types or literal values.
Minimizer Notes:
ir_minimizer_main crashed with OOM (tcmalloc) when attempting to minimize sample.ir, though it produced a partially minimized file (minimized.ir) which completely folded the logic into the literal return shown above.
Failure Details:
eval_ir_maintimes out when executing the IR via LLVM JIT (--use_llvm_jit).Reproduction:
(Using files extracted from
crasher_2026-05-23_85e7.x)Root Cause:
The top function has a complex return type containing a large array of tuples:
-> (bits[1], (bits[1], bits[1], bits[1], bits[1])[1818])Even when the IR is minimized to simply return a literal of this type:
LLVM JIT (
eval_ir_main) still hangs/timeouts even with a single input vector.This suggests the issue is in how LLVM or the XLS LLVM JIT bridge handles extremely large or complex return types or literal values.
Minimizer Notes:
ir_minimizer_maincrashed with OOM (tcmalloc) when attempting to minimizesample.ir, though it produced a partially minimized file (minimized.ir) which completely folded the logic into the literal return shown above.