[llvm-dev] [RFC] Vector Predication (original) (raw)

Simon Moll via llvm-dev llvm-dev at lists.llvm.org
Fri Feb 1 01:54:40 PST 2019

Hi,

On 1/31/19 11:20 PM, Jacob Lifshay wrote:

We're in-progress designing a RISC-V extension (http://lists.libre-riscv.org/pipermail/libre-riscv-dev/2019-January/000433.html) that would have variable-length vectors of short vectors (1 to 4): <VL x <4 x float>> where each predicate bit masks out a whole short vector. We're using this extension to vectorize graphics code where where variables in the pre-vectorization code are short vectors. So, vectorizing code like: for(int i = 0; i < 1000; i++) { vec4 color = colors[i]; vec3 normal = normals[i]; color.rgb *= fmax(0.0, dot(normal, lightdir)); colors[i] = color; }

I'm planning on passing already vectorized code into LLVM and using LLVM as a backend for optimization and JIT code generation. Do you think the EVL proposal would support an ISA like this as it's currently written (by pattern matching on predicate expansion and vector-length multiplication)? Or, do you think the EVL proposal would need modification to effectively support this (by adding a element group size argument to EVL intrinsics or something)?

We could untie the mask length from the data length:

  %result = call <scalable 4 x float> @llvm.evl.fsub.v4f32(<scalable 4 x float> %x, <scalable 4 x float> %y, <scalable 1 x i1> %M, i32 %L)

would then indicate the the mask %M applies to groups of "4 / 1" float elements.

Jacob Lifshay > On Thu, Jan 31, 2019, 07:58 Simon Moll via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> wrote: > Hi, > There is now an RFC for a roadmap to native vector predication support in LLVM and a prototype implementation: > https://reviews.llvm.org/D57504 > The prototype demonstrates: > -  Predicated vector intrinsics with an explicit mask and vector length parameter on IR level. -  First-class predicated SDNodes on ISel level. Mask and vector length are value operands. -  An incremental strategy to generalize PatternMatch/InstCombine/InstSimplify and DAGCombiner to work on both regular instructions and EVL intrinsics. -  DAGCombiner example: FMA fusion. -  InstCombine/InstSimplify example: FSub pattern re-writes. -  Early experiments on the LNT test suite (Clang static release, O3 -ffast-math) indicate that compile time on non-EVL IR is not affected by the API abstractions in PatternMatch, etc. > We’d like to get your feedback, in particular on the following to move forward: > -  Can we agree on EVL intrinsics as a transitional step to predicated IR instructions? -  Can we agree on native EVL SDNodes for CodeGen? -  Are the changes to InstCombine/InstSimplify/DAGCombiner and utility classes that go with it acceptable? > Thanks Simon > -- > Simon Moll Researcher / PhD Student > Compiler Design Lab (Prof. Hack) Saarland University, Computer Science Building E1.3, Room 4.31 > Tel. +49 (0)681 302-57521 :moll at cs.uni-saarland.de <mailto:moll at cs.uni-saarland.de> Fax. +49 (0)681 302-3065 :http://compilers.cs.uni-saarland.de/people/moll > _________________________ LLVM Developers mailing list llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

Simon Moll Researcher / PhD Student

Compiler Design Lab (Prof. Hack) Saarland University, Computer Science Building E1.3, Room 4.31

Tel. +49 (0)681 302-57521 : moll at cs.uni-saarland.de Fax. +49 (0)681 302-3065 : http://compilers.cs.uni-saarland.de/people/moll

-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190201/322abdca/attachment-0001.html>

More information about the llvm-dev mailing list