[PATCH] D57504: RFC: EVL Prototype & Roadmap for vector predication in LLVM

Fri Feb 1 05:59:45 PST 2019

simoll marked an inline comment as done.
simoll added a comment.

In D57504#1380504 <https://reviews.llvm.org/D57504#1380504>, @programmerjake wrote:

> We will also need to adjust gather/scatter and possibly other load/store kinds to allow the address vector length to be a divisor of the main vector length (similar to mask vector length). I didn't check if there are intrinsics for strided load/store, those will need to be changed too, to allow, for example, storing <scalable 3 x float> to var.v in:

.. and as a side effect evl_load/evl_store are subsumed by evl_gather/evl_scatter:

  evl.load(%p, %M, %L) ==  evl.gather(<1 x double*> %p, <256 x i1>..) ==  evl.gather(double* %p, <256 x i1> %M, i32 %L)

Nice :)

Regarding strided memory accesses, i was hoping the stride could be pattern matched in the backend.

================
Comment at: include/llvm/IR/Intrinsics.td:1132
+                                LLVMMatchType<0>,
+                                LLVMScalarOrSameVectorWidth<0, llvm_i1_ty>,
+                                llvm_i32_ty]>;
----------------
programmerjake wrote:
> We will need to change the mask parameter length to allow for mask lengths that are a divisor of the main vector length.
> See http://lists.llvm.org/pipermail/llvm-dev/2019-February/129845.html
Can we make the vector length operate at the granularity of the mask?

In your case [1] that would mean that the AVL refers to multiples of the short element vector (eg `<3 x float>`).

[1] http://lists.libre-riscv.org/pipermail/libre-riscv-dev/2019-January/000433.html

Repository:
  rL LLVM

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D57504/new/

https://reviews.llvm.org/D57504