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

Simon Moll via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Wed Feb 6 12:49:25 PST 2019


simoll added a comment.

In D57504#1386491 <https://reviews.llvm.org/D57504#1386491>, @lkcl wrote:

> > Certainly, that's why I say it's secondary and mostly a hint that something is amiss with "the current thinking". In fact, I am by now inclined to propose that Jacob and collaborators start out by expressing their architecture's operations with target-specific intrinsics that also use the attributes introduced here (especially since none of the typical vectorizers are equipped to generate the sort of code they want from scalar code using e.g. float4 types).
>
> just so you know: we're not using a "typical vectoriser", we are writing our own, and it is very very specifically designed to accommodate the float3 and float4 datatypes.  it is a SPIR-V to LLVM-IR compiler (used by both OpenCL and 3D Shaders compatible with the Vulkan API).  to reiterate: we are *not* expecting to vector-augment or even use clang-llvm, rustlang-llvm or other vectoriser, we are *directly* translating SPIR-V IR into LLVM IR.


Err.. re-vectorizing float3/float4 codes will mostly concern the vectorizer backend ("widening phase"), all other stages should accept vectors as "scalar" data types. I am talking about RV here, of course (https://github.com/cdl-saarland/rv) ;-)

> so LLVM IR having these vectorisation features is important (for the Kazan Project), yet, bizarrely, front-end support for vectorisation is *not* important (for the Kazan Project).
> 
>> Alternatively, use a dynamic vector length of <the length their architecture wants> * <how many elements each of the short vectors has> and fix it up in the backend.
> 
> remember that both RVV and SV support the exact same vscale (variable-length multiples of elements) concept.

We've already agreed that the unit of the vlen parameter is just the element type (that is the sub-vector element type in the vector-of-subvector interpretation of scalable types).


Repository:
  rL LLVM

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

https://reviews.llvm.org/D57504





More information about the llvm-commits mailing list