<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>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.</p>
<p>I'm going to use fsub as my running example, just because it's
the first IR test you posted. :)</p>
<p>%result = call <4 x float> @llvm.evl.fsub.v4f32(<4 x
float> %x, <4 x float> %y, <4 x i1> %M, i32 %L)</p>
<p>Question 1 - Why do we need separate mask and lengths? Can't the
length be easily folded into the mask operand? <br>
<br>
e.g. newmask = (<4 x i1>)((i4)%y & (1 << %L -1))<br>
and then pattern matched in the backend if needed<br>
</p>
<p>Question 2 - Have you explored using selects instead? What
practical problems do you run into which make you believe explicit
predication is required?</p>
<p>e.g. %sub = fsub <4 x float> %x, %y<br>
%result = select <4 x i1> %M, <4 x float>
%sub, undef</p>
<p>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.<br>
</p>
<p>Philip<br>
</p>
<div class="moz-cite-prefix">On 1/31/19 7:58 AM, Simon Moll via
llvm-dev wrote:<br>
</div>
<blockquote type="cite"
cite="mid:573319c8-847c-8480-e43b-d9ebb988cf98@cs.uni-saarland.de">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
Hi,<br>
<br>
There is now an RFC for a roadmap to native vector predication
support in LLVM and a prototype implementation:<br>
<br>
<a class="moz-txt-link-freetext"
href="https://reviews.llvm.org/D57504" moz-do-not-send="true">https://reviews.llvm.org/D57504</a><br>
<br>
The prototype demonstrates:<br>
<br>
- Predicated vector intrinsics with an explicit mask and vector
length parameter on IR level.<br>
- First-class predicated SDNodes on ISel level. Mask and vector
length are value operands.<br>
- An incremental strategy to generalize
PatternMatch/InstCombine/InstSimplify and DAGCombiner to work on
both regular instructions and EVL intrinsics.<br>
- DAGCombiner example: FMA fusion.<br>
- InstCombine/InstSimplify example: FSub pattern re-writes.<br>
- 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.<br>
<br>
We’d like to get your feedback, in particular on the following to
move forward:<br>
<br>
- Can we agree on EVL intrinsics as a transitional step to
predicated IR instructions?<br>
- Can we agree on native EVL SDNodes for CodeGen?<br>
- Are the changes to InstCombine/InstSimplify/DAGCombiner and
utility classes that go with it acceptable?<br>
<br>
Thanks<br>
Simon<span style="font-size: 11pt; color: rgb(0, 0, 0); background-color: transparent; font-weight: 400; font-style: normal; font-variant: normal; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;"></span><span style="font-size: 11pt; color: rgb(0, 0, 0); background-color: transparent; font-weight: 400; font-style: normal; font-variant: normal; text-decoration: none; vertical-align: baseline; white-space: pre-wrap;"></span>
<pre class="moz-signature" cols="72">--
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 : <a class="moz-txt-link-abbreviated" href="mailto:moll@cs.uni-saarland.de" moz-do-not-send="true">moll@cs.uni-saarland.de</a>
Fax. +49 (0)681 302-3065 : <a class="moz-txt-link-freetext" href="http://compilers.cs.uni-saarland.de/people/moll" moz-do-not-send="true">http://compilers.cs.uni-saarland.de/people/moll</a></pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
LLVM Developers mailing list
<a class="moz-txt-link-abbreviated" href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>
<a class="moz-txt-link-freetext" href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a>
</pre>
</blockquote>
</body>
</html>