[llvm-dev] [RFC] Vector Predication

[Philip Reames via llvm-dev]

Can I start w/some basic questions?   I've skimmed your proposal, but 
haven't read it in detail, so if something I ask is already addressed, 
please feel free to cite existing docs/discussion/whatever.

I'm going to use fsub as my running example, just because it's the first 
IR test you posted. :)

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

Question 1 - Why do we need separate mask and lengths?  Can't the length 
be easily folded into the mask operand?

e.g. newmask = (<4 x i1>)((i4)%y & (1 << %L -1))
and then pattern matched in the backend if needed

Question 2 - Have you explored using selects instead?  What practical 
problems do you run into which make you believe explicit predication is 
required?

e.g. %sub = fsub <4 x float> %x, %y
         %result = select <4 x i1> %M, <4 x float> %sub, undef

My context for these questions is that my experience recently w/o 
existing masked intrinsics shows us missing fairly basic optimizations, 
precisely because they weren't able to reuse all of the existing 
infrastructure.  (I've been working on SimplifyDemandedVectorElts 
recently for exactly this reason.)  My concern is that your EVL proposal 
will end up in the same state.

Philip

On 1/31/19 7:58 AM, Simon Moll via llvm-dev 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
> Fax. +49 (0)681 302-3065  :http://compilers.cs.uni-saarland.de/people/moll
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190131/8156a40b/attachment-0001.html>