But for some reason mlir-opt returns an error which I don’t understand yet:
custom op ‘llvm.mlir.global’ expected linkage
I also don’t see how I could specify a fixed address for a global variable.
BTW: if you wonder why I’m doing this - I’m still not yet happy with my understanding of tiling, and I want to understand the source of some speed variations. One source I want to investigate is indeed the alignment of the various matrices.
This is a very good question. I’m experienced with low-level C code generation, but I have no experience with LLVMIR.
In low-level C, at least part of the information is provided as part of a linker script. You need to do this in order (for instance) to guarantee performance by guaranteeing relative alignment between variables, and thus consistent cache behavior.
The attributes of gcc/llvm allow the encoding of alignment, but:
I don’t know how LLVM encodes this (I have no experience with LLVMIR).
There are things LLVM does not cover, as they are covered by linking. I was wondering if MLIR is meant to cover them (such as allocating a variable to a precise address).
Related to the last point: Is mlir-cpu-runner able to take into account linker-script-level information?
If you have C input, you can see the LLVM IR produced by clang by running clang input.c -S -emit-llvm and inspecting input.ll.
MLIR may have a dialect for virtually anything, but I’m unaware of any linking-related dialect atm. I expect linking to be mostly symbol name-based, so if you get MLIR to produce LLVM with the symbol names your linker expects, chances are you can use the same linker flags.