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

[Simon Moll via Phabricator via llvm-commits]

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


================
Comment at: include/llvm/IR/Intrinsics.td:1132
+                                LLVMMatchType<0>,
+                                LLVMScalarOrSameVectorWidth<0, llvm_i1_ty>,
+                                llvm_i32_ty]>;
----------------
programmerjake wrote:
> simoll wrote:
> > 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
> I was initially assuming that the vector length would be in the granularity of the mask.
> That would work for my ISA extension. I think that would work for the RISC-V V extension, would have to double check, or get someone who's working on it to check. I don't think that would work without needing to multiply the vector length on AVX512, assuming a shift is used to generate the mask. I have no clue for ARM SVE or other architectures.
So we are on the same page here.

What i actually had in mind is how this would interact with scalable vectors,e.g.:

   <scalable 2 x float> evl.fsub(<scalable 2 x float> %x, <scalable 2 x float> %y, <scalable 2 x i1> %M, i32 %L) 

In that case, the vector length should refer to packets of two elements. That would be a perfect match for NEC SX-Aurora, where AVL always refers to 64 bit elements (eg there is a packed float mode).


Repository:
  rL LLVM

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

https://reviews.llvm.org/D57504