Open meheff opened 3 years ago
Also seems to require wide types and an odd number of bits for the function parameter.
Looks like the LLVM IR-level optimizations are ok: https://alive2.llvm.org/ce/z/8UB2Rg. See alive output below.
This suggests this might be a codegen bug in LLVM.
Alive output:
define i122 @f(i61 %x0) { %0: %x1 = add i61 %x0, %x0 %reverse_19 = bitreverse i61 %x1 %_7 = zext i61 %reverse_19 to i122 %_8 = shl i122 %_7, 61 %_9 = or i122 0, %_8 %_10 = zext i61 %reverse_19 to i122 %_11 = shl i122 %_10, 0 %x12 = or i122 %_9, %_11 ret i122 %x12 } => define i122 @f(i61 %x0) { %0: %x1 = shl i61 %x0, 1 %reverse_19 = bitreverse i61 %x1 %_7 = zext i61 %reverse_19 to i122 %x12 = mul nsw nuw i122 %_7, 2305843009213693953 ret i122 %x12 } Transformation seems to be correct!
Summary: 1 correct transformations 0 incorrect transformations 0 Alive2 errors
This has a simple reduced test case:
Running eval main:
With the JIT:
With the interpreter:
With the JIT without optimizations
Unfortunately does not repro outside of the JIT (with lli, or llc followed by gcc to generate an executable). For the record a self contained ll file: