Bus Error in MLIR/LLVM Compiler Pipeline

MLIR
1

Hi everyone,

I am currently researching bugs in compiler pipelines and have come across an issue that I would like to discuss. I have encountered a situation where the specific code below leads to a bus error when directly lowered to LLVM IR and compiled with LLC and Clang.

MLIR:

module {
  func.func @main() -> i32 {
    %alloca = memref.alloca() : memref<100000x100000x100000xi8>
    %alloc = memref.alloc() : memref<2x100000x1xi16>
    %c0 = arith.constant 0 : i32
    return %c0  : i32
  }
}

Pipeline:

mlir-opt --lower-host-to-llvm input.mlir | mlir-translate --mlir-to-llvmir | llc -O3 --relocation-model=pic -o asm.s && clang -O0 -fPIC -march=native asm.s && ./a.out

Interestingly, if I remove one of the allocations or change its type (i.e., alloca to alloc or alloc to alloca), everything works fine. I would expect both allocations to be eliminated by LLC’s DCE, regardless of heap or stack allocation. Considering that the stack allocation is so large, it’s reasonable to keep the alloca in order to preserve program behavior. However, I would then expect the same error after replacing the second line with alloca.

I would appreciate any insights on this, in particular if it’s expected behavior and if so why.

2

The llvm optimizer is ˋopt` actually. I would use clang instead of llc to process the output of mlir-translate.

1 Like
3

Thanks for the hint. Works as expected using opt or clang.

Would we not expect llc -O3 to also eliminate the allocations?

4

llc is only the backend of LLVM: it performs instruction selection from LLVM IR to Machine IR and scheduling and register allocation.
It also has some optimization but they aren’t meant to be redundant with LLVM IR level optimizations, so it may or may not do something for simple cases, but it’s design to assume that the heavy lifting is done at the LLVM IR level: it won’t try to re-do everything.

1 Like