Update
- Sync to the vector type with scalable dimensions.
- Set the
vtaas an attribute. - Add
setvloperation. - Some RISC-V + JIT progress (needed by integration test)
Here is the current RISCVV dialect patch .
Sync to the vector type with scalable dimensions.
According to the previous discussion, I sync the type to the built-in vector type with scalable dimensions.
Set the vta as an attribute.
The llvm intrinsic add vta argument to let users control the tail policy, see the patch for more details. Here I quote the sentences from the patch to show the meaning of the tail agnostic and tail undisturbed:
Tail agnostic means users do not care about the values in the tail elements and tail undisturbed means the values in the tail elements need to be kept after the operation.
Since the vta parameter is a tail policy option, it is more appropriate to be an attribute in MLIR. And the lowering pass is responsible for converting the attribute into an intrinsic argument.
Add setvl operation.
vsetvli is an useful instruction for RISC-V vector extension to set vector length according to the AVL, SEW, LMUL configurations. RVV uses this to achieve a direct and portable strip-mining approach, which is purposed to handle a large number of elements. The return value of this instruction is the number of elements for a single iteration. In this case, the vsetvli can help with strip-mining for loop iterations, which is different from the SIMD style (using masks for the tail processing).
After adding this operation, we can use strip-mining style loop iterations in MLIR for RVV target. I prepare an example to show this.
https://gist.github.com/zhanghb97/db87cd22d330ba6424b31c70b135b0ca#file-test-rvv-stripmining-mlir
Some RISC-V + JIT progress (needed by integration test)
My teammate has sent some patches hoping to support JIT for the RISC-V side.
Here I quote some sentences of his summary to show the point of the challenge:
In RISCV, temporary symbols will be used to generate dwarf, eh_frame sections…, and will be placed in object code’s symbol table. However, LLVM does not use names on these temporary symbols.
For more details, please see his patches: