The following with add
@buff_src = external global [128 x i32]
@buff_dst = external global [128 x i32]
define void @add() {
%1 = load <32 x i16>, ptr @buff_src, align 256
%2 = load <32 x i16>, ptr @buff_src, align 256
add <32 x i16> %1, %2
store <32 x i16> %3, ptr @buff_dst, align 256
ret void
}
compiles fine with
llc input.ll -O2 --march=aie2p --filetype=asm -o out.s
with the following in the output
vadd.16 x0, x0, x2 // Delay Slot 4
Change the add to mul:
[...]
mul <32 x i16> %1, %2
[...]
and it fails with
Unnable to legalize instruction: %3:_(<32 x s16>) = G_MUL %0:_, %2:_ (in function: add)
I can see that mlir-aie's aievec gets around (on the MLIR -> LLVM IR path) by intercepting the mul (at the MLIR level) and converting it to something else which targets the correct intrinsic:
https://github.com/Xilinx/mlir-aie/blob/0ce127c3835a6777538f37c397385a7f1ecd8108/include/aie/Dialect/XLLVM/IR/XLLVMAIE2IntrOps.td#L90
My question is would it make sense to support this directly in instruction selection on peano's side?
The following with
addcompiles fine with
with the following in the output
Change the
addtomul:and it fails with
I can see that mlir-aie's aievec gets around (on the MLIR -> LLVM IR path) by intercepting the mul (at the MLIR level) and converting it to something else which targets the correct intrinsic:
https://github.com/Xilinx/mlir-aie/blob/0ce127c3835a6777538f37c397385a7f1ecd8108/include/aie/Dialect/XLLVM/IR/XLLVMAIE2IntrOps.td#L90
My question is would it make sense to support this directly in instruction selection on peano's side?