[fuzzer: 6bbb647c] XLS JIT produces incorrect results

[ericastor]

Describe the bug eval_ir_main produces different results for the following IR with the interpreter and the JIT:

package sample

top fn __sample__main(x0: bits[28] id=1) -> ((bits[1], bits[17]), bits[51]) {
  bit_slice.396: bits[1] = bit_slice(x0, start=0, width=1, id=396)
  zero_ext.357: bits[3] = zero_ext(bit_slice.396, new_bit_count=3, id=357)
  literal.382: (bits[1], bits[17]) = literal(value=(0, 7789), id=382)
  literal.346: (bits[1], bits[17]) = literal(value=(0, 0), id=346)
  x3: (bits[1], bits[17]) = priority_sel(zero_ext.357, cases=[literal.382, literal.346, literal.346], default=literal.346, id=45)
  x7: bits[1] = literal(value=0, id=312)
  x4: bits[1] = tuple_index(x3, index=0, id=46)
  literal.376: bits[3] = literal(value=0, id=376)
  concat.303: bits[33] = concat(x0, x7, x4, literal.376, id=303)
  x8: bits[51] = zero_ext(concat.303, new_bit_count=51, id=289)
  ret tuple.395: ((bits[1], bits[17]), bits[51]) = tuple(x3, x8, id=395)
}

This was discovered with our fuzzer as crasher_2024-09-14_6bbb.x, then minimized.

To Reproduce Run eval_ir_main over the above IR, passing --input='bits[28]:0x1' --test_llvm_jit.

Expected behavior Results should agree between the interpreter and the JIT.

Additional context This appears to be an LLVM bug; the issue goes away if we turn off LLVM optimization. I've used //xls/dev_tools:dump_llvm_artifacts to create a self-contained demonstration of the issue, and filed it as llvm/llvm-project#108828