[llvm-dev] [RFC] Vector Predication
Philip Reames via llvm-dev
llvm-dev at lists.llvm.org
Thu Jan 31 09:02:36 PST 2019
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
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.
On 1/31/19 7:58 AM, Simon Moll via llvm-dev wrote:
> There is now an RFC for a roadmap to native vector predication support
> in LLVM and a prototype implementation:
> 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
> - 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?
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev