Open zzzDavid opened 1 year ago
This is a bug in MLIR's JIT compiler.
Test case
module { func.func private @printMemrefI32(%ptr : memref<*xi32>) func.func @top () -> () { // allocate a memref<1xi32> and store a constant 50 into it %0 = memref.alloc() : memref<1xi32> %1 = arith.constant 50 : i32 affine.store %1, %0[0] : memref<1xi32> // load the value from memref and shift left for 32 bits %2 = affine.load %0[0] : memref<1xi32> %cst_32 = arith.constant 32 : i32 %3 = arith.shli %2, %cst_32 : i32 // store it back to memref affine.store %3, %0[0] : memref<1xi32> // print memref %casted_memref = memref.cast %0 : memref<1xi32> to memref<*xi32> call @printMemrefI32(%casted_memref) : (memref<*xi32>) -> () return } func.func @main() -> () { call @top() : () -> () return } }
Use MLIR JIT CPU runner:
mlir-opt main.mlir \ --lower-affine \ --convert-scf-to-cf \ --convert-cf-to-llvm \ --convert-memref-to-llvm \ --convert-arith-to-llvm \ --convert-func-to-llvm \ --reconcile-unrealized-casts \ | mlir-cpu-runner -e main --O1 \ --entry-point-result=void \ --shared-libs=/work/shared/users/phd/nz264/llvm-project/build/lib/libmlir_c_runner_utils.so \ --shared-libs=/work/shared/users/phd/nz264/llvm-project/build/lib/libmlir_runner_utils.so
MLIR cpu runner prints 50, the correct result should be 0.
50
Use translate to llvm IR -> llc -> gcc compilation:
hcl-opt main.mlir --lower-to-llvm | \ mlir-translate -mlir-to-llvmir | \ opt -O3 -S | \ llc -O3 -filetype=obj -o demo.o gcc demo.o \ -L/work/shared/users/phd/nz264/mlir/hcl-dialect/build/lib/ \ -lhcl_runtime_utils \ -L/work/shared/users/phd/nz264/llvm-project/build/lib/ \ -lmlir_c_runner_utils \ -lmlir_runner_utils \ -o demo
Executing demo prints the correct result 0.
demo
0
Right now we are using a bypass to avoid this case because we are using the JIT backend in HeteroCL. See here:
https://github.com/cornell-zhang/heterocl/blob/6a3015bf1c36a919f857b525e8f9043e60c11558/python/heterocl/ast/ir_builder.py#L619-L631
I will file an issue for this in the LLVM repository and post it here
This is a bug in MLIR's JIT compiler.
Test case
Use MLIR JIT CPU runner:
MLIR cpu runner prints
50
, the correct result should be 0.Use translate to llvm IR -> llc -> gcc compilation:
Executing
demo
prints the correct result0
.