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

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 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>

More information about the llvm-dev mailing list