<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
</head>
<body>
<div class="moz-cite-prefix">On 5/19/20 5:22 PM, Sjoerd Meijer wrote:<br>
</div>
<blockquote type="cite" cite="mid:DB6PR0801MB199039BB8CD06A5E1042A729FCB90@DB6PR0801MB1990.eurprd08.prod.outlook.com">
<style type="text/css" style="display:none;"> P {margin-top:0;margin-bottom:0;} </style>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif;
font-size: 12pt; color: rgb(0, 0, 0);">
Invitation accepted, I am happy to help out with reviews, like I did with the previous VP patches.</div>
</blockquote>
That's great!<br>
<blockquote type="cite" cite="mid:DB6PR0801MB199039BB8CD06A5E1042A729FCB90@DB6PR0801MB1990.eurprd08.prod.outlook.com">
<div style="font-family: Calibri, Arial, Helvetica, sans-serif;
font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif;
font-size: 12pt; color: rgb(0, 0, 0);">
And of course agreed that things should be well defined, and that we shouldn't paint ourselves in a corner, but I don't think that this is the case. And it's not that I am in a rush, but I don't think this change needs to be predicated on a big change landing
first like the LV switching to VP intrinsics.</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif;
font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif;
font-size: 12pt; color: rgb(0, 0, 0);">
> The difference is that in the VP version there is an explicit dependence of every vector operation in the loop to the
<tt>set.num.elements</tt> intrinsic. This dependence is obscured in the hwloop proposals (more on that below).</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif;
font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif;
font-size: 12pt; color: rgb(0, 0, 0);">
This discussion is getting complicated, because I think we are discussing 3 topics at the same time now: predication, hardware loops, and a new set of intrinsics, the VP intrinsics.</div>
</blockquote>
Ok. My questions (the example at the end) was asking whether hwloops imply predication (and by that i mean logically - if the hwloop implies that a SIMD instruction may not execute for all lanes in the tail then that is predication as well).
<br>
<blockquote type="cite" cite="mid:DB6PR0801MB199039BB8CD06A5E1042A729FCB90@DB6PR0801MB1990.eurprd08.prod.outlook.com">
<div style="font-family: Calibri, Arial, Helvetica, sans-serif;
font-size: 12pt; color: rgb(0, 0, 0);">
For the change that kicked off this thread, i.e. 1 new intrinsic to get the active lanes, I think we can eliminate the hardware loops from this story. For us, that is just the context of this, and so I think we can just focus on predication. And if we only
talk about predication, I think this new intrinsic can nicely coexist with the VP intrinsics.</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif;
font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif;
font-size: 12pt; color: rgb(0, 0, 0);">
And please note again I am not proposing a set.num.elements intrinsic. Well, I first kind of did, but again, abandoned that approach after push back. Correct me if I am wrong, but there's no difference in your example whether all instructions consume some predicate
or only masked loads/stores: <br>
</div>
</blockquote>
Yes, and that is the point: it's about making the SIMD instructions dependent on the mask .. and all of them.<br>
<blockquote type="cite" cite="mid:DB6PR0801MB199039BB8CD06A5E1042A729FCB90@DB6PR0801MB1990.eurprd08.prod.outlook.com">
<div style="font-family: Calibri, Arial, Helvetica, sans-serif;
font-size: 12pt; color: rgb(0, 0, 0);">
</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif;
font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif;
font-size: 12pt; color: rgb(0, 0, 0);">
<tt><tt><span style="font-family: calibri, arial, helvetica,
sans-serif; font-size: 12pt; line-height: normal; color:
rgb(0, 0, 0); background-color: rgba(0, 0, 0, 0);"> vector.preheader:</span></tt><tt><br>
</tt><tt><span style="font-family: calibri, arial, helvetica,
sans-serif; font-size: 12pt; line-height: normal; color:
rgb(0, 0, 0); background-color: rgba(0, 0, 0, 0);"> %init.evl = i32 llvm.hwloop.set.elements(%n)</span></tt><br>
<tt><span style="font-family: calibri, arial, helvetica,
sans-serif; font-size: 12pt; line-height: normal; color:
rgb(0, 0, 0); background-color: rgba(0, 0, 0, 0);"> vector.body:</span></tt><tt><br>
</tt><tt><span style="font-family: calibri, arial, helvetica,
sans-serif; font-size: 12pt; line-height: normal; color:
rgb(0, 0, 0); background-color: rgba(0, 0, 0, 0);"> %evl = phi 32 [%init.evl, %preheader, %next.evl, vector.body]</span></tt><tt><br>
</tt><tt><span style="font-family: calibri, arial, helvetica,
sans-serif; font-size: 12pt; line-height: normal; color:
rgb(0, 0, 0); background-color: rgba(0, 0, 0, 0);"> %aval = call @llvm.vp.load(Aptr, .., %evl)</span></tt><tt><br>
</tt><tt><span style="font-family: calibri, arial, helvetica,
sans-serif; font-size: 12pt; line-height: normal; color:
rgb(0, 0, 0); background-color: rgba(0, 0, 0, 0);"> call @llvm.vp.store(Bptr, %aval, ..., %evl)</span></tt><tt><br>
</tt><tt><span style="font-family: calibri, arial, helvetica,
sans-serif; font-size: 12pt; line-height: normal; color:
rgb(0, 0, 0); background-color: rgba(0, 0, 0, 0);"> %next.evl = call i32 @llvm.hwloop.decrement(%evl)</span></tt></tt></div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif;
font-size: 12pt; color: rgb(0, 0, 0);">
<tt><tt><br>
</tt></tt></div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif;
font-size: 12pt; color: rgb(0, 0, 0);">
<tt><tt><span style="font-family: calibri, arial, helvetica,
sans-serif; font-size: 12pt; line-height: normal; color:
rgb(0, 0, 0); background-color: rgba(0, 0, 0, 0);">No difference in that the probl</span><span style="font-family: calibri, arial, helvetica, sans-serif;
font-size: 12pt; line-height: normal; color: rgb(0, 0, 0);
background-color: rgba(0, 0, 0, 0);">em
remains that we have a random intrinsic sitting in the preheader describing a loop property that needs to be maintained.</span></tt></tt></div>
</blockquote>
The difference is that the intrinsic is connected to every SIMD instruction in the vector loop through data flow. It does not just sit there.. in fact it does not matter where it is placed as long as those def-use edges are visible to the hwloop transformation.<br>
<blockquote type="cite" cite="mid:DB6PR0801MB199039BB8CD06A5E1042A729FCB90@DB6PR0801MB1990.eurprd08.prod.outlook.com">
<div style="font-family: Calibri, Arial, Helvetica, sans-serif;
font-size: 12pt; color: rgb(0, 0, 0);">
<tt><tt><span style="font-family: calibri, arial, helvetica,
sans-serif; font-size: 12pt; line-height: normal; color:
rgb(0, 0, 0); background-color: rgba(0, 0, 0, 0);"><br>
</span></tt></tt></div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif;
font-size: 12pt; color: rgb(0, 0, 0);">
<tt><tt><span style="font-family: calibri, arial, helvetica,
sans-serif; font-size: 12pt; line-height: normal; color:
rgb(0, 0, 0); background-color: rgba(0, 0, 0, 0);">So, eliminating hardware loops and intrinsic that defines the
number of elements produced, I am proposing</span></tt></tt></div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif;
font-size: 12pt; color: rgb(0, 0, 0);">
<tt><tt><span style="font-family: calibri, arial, helvetica,
sans-serif; font-size: 12pt; line-height: normal; color:
rgb(0, 0, 0); background-color: rgba(0, 0, 0, 0);"><br>
</span></tt></tt></div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif;
font-size: 12pt; color: rgb(0, 0, 0);">
<tt><tt><span style="font-family: calibri, arial, helvetica,
sans-serif; font-size: 12pt; line-height: normal; color:
rgb(0, 0, 0); background-color: rgba(0, 0, 0, 0);"><tt><tt><span style="font-size: 12pt; line-height: normal;
background-color: rgba(0, 0, 0, 0); font-family:
calibri, arial, helvetica, sans-serif; color: rgb(0,
0, 0);">
vector.body:</span></tt></tt><br>
</span></tt></tt></div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif;
font-size: 12pt; color: rgb(0, 0, 0);">
<tt><tt><span style="font-family: calibri, arial, helvetica,
sans-serif; font-size: 12pt; line-height: normal; color:
rgb(0, 0, 0); background-color: rgba(0, 0, 0, 0);"><span><span> %mask = lvm.get.active.lane.mask (%IV, %BTC)</span></span></span></tt></tt></div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif;
font-size: 12pt; color: rgb(0, 0, 0);">
<tt><tt><span style="font-family: calibri, arial, helvetica,
sans-serif; font-size: 12pt; line-height: normal; color:
rgb(0, 0, 0); background-color: rgba(0, 0, 0, 0);"><span><span><span> .. = @llvm.masked.load</span>(.., %mask)<br>
</span></span></span></tt></tt></div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif;
font-size: 12pt; color: rgb(0, 0, 0);">
<tt><tt><span style="font-family: calibri, arial, helvetica,
sans-serif; font-size: 12pt; line-height: normal; color:
rgb(0, 0, 0); background-color: rgba(0, 0, 0, 0);"><span><span><br>
</span></span></span></tt></tt></div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif;
font-size: 12pt; color: rgb(0, 0, 0);">
<tt><tt><span style="font-family: calibri, arial, helvetica,
sans-serif; font-size: 12pt; line-height: normal; color:
rgb(0, 0, 0); background-color: rgba(0, 0, 0, 0);"><span><span>where IV is the induction step, and BTC the backedge
taken count. <br>
</span></span></span></tt></tt></div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif;
font-size: 12pt; color: rgb(0, 0, 0);">
<tt><tt><span style="font-family: calibri, arial, helvetica,
sans-serif; font-size: 12pt; line-height: normal; color:
rgb(0, 0, 0); background-color: rgba(0, 0, 0, 0);"><span><span>This completely piggy backs on everything that is
already there in the vectoriser, and nothing is fundamentally changed here. Now, this seems very generic, and doesn't seem to bite the VP intrinsics.<br>
</span></span></span></tt></tt></div>
</blockquote>
I see it the other way round: Right now you seem to have an implicit dependence from syntactically unmasked SIMD instructions (eg a regular SIMD sdiv) to the predicate of nearby masked intrinsics (masked.load) - that's on shaky grounds semantically. VP intrinsics
already define a clean semantics for tail predication - so why not piggyback on that? You should define the hwloop support in a way that will not just peacefully coexist with VP but leverage it eventually. I'll continue in that direction in the review.<br>
<br>
One specific request (since i got you attention now ;-) ): we need a (generic) IR primitive to express %lane_id < %n for scalable vector types to expand VP intrinsics for targets with SVE support but no tail predication.<br>
<blockquote type="cite" cite="mid:DB6PR0801MB199039BB8CD06A5E1042A729FCB90@DB6PR0801MB1990.eurprd08.prod.outlook.com">
<div style="font-family: Calibri, Arial, Helvetica, sans-serif;
font-size: 12pt; color: rgb(0, 0, 0);">
<tt><tt><span style="font-family: calibri, arial, helvetica, sans-serif;
font-size: 12pt; line-height: normal; color: rgb(0, 0, 0);
background-color: rgba(0, 0, 0, 0);"><span><span></span></span></span></tt></tt></div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif;
font-size: 12pt; color: rgb(0, 0, 0);">
<tt><tt><span style="font-family: calibri, arial, helvetica,
sans-serif; font-size: 12pt; line-height: normal; color:
rgb(0, 0, 0); background-color: rgba(0, 0, 0, 0);"><span><span><br>
</span></span></span></tt></tt></div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif;
font-size: 12pt; color: rgb(0, 0, 0);">
<tt><tt><span style="font-family: calibri, arial, helvetica,
sans-serif; font-size: 12pt; line-height: normal; color:
rgb(0, 0, 0); background-color: rgba(0, 0, 0, 0);"><span><span>Cheers,</span></span></span></tt></tt></div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif;
font-size: 12pt; color: rgb(0, 0, 0);">
<tt><tt><span style="font-family: calibri, arial, helvetica,
sans-serif; font-size: 12pt; line-height: normal; color:
rgb(0, 0, 0); background-color: rgba(0, 0, 0, 0);"><span><span>Sjoerd.<br>
</span></span></span></tt></tt></div>
</blockquote>
- Simon<br>
<blockquote type="cite" cite="mid:DB6PR0801MB199039BB8CD06A5E1042A729FCB90@DB6PR0801MB1990.eurprd08.prod.outlook.com">
<div style="font-family: Calibri, Arial, Helvetica, sans-serif;
font-size: 12pt; color: rgb(0, 0, 0);">
<tt><tt><span style="font-family: calibri, arial, helvetica, sans-serif;
font-size: 12pt; line-height: normal; color: rgb(0, 0, 0);
background-color: rgba(0, 0, 0, 0);"><span><span></span></span></span></tt></tt></div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;
font-size:12pt; color:rgb(0,0,0)">
<br>
</div>
<hr tabindex="-1" style="display:inline-block; width:98%">
<div id="divRplyFwdMsg" dir="ltr"><font style="font-size:11pt" face="Calibri, sans-serif" color="#000000"><b>From:</b> Simon Moll
<a class="moz-txt-link-rfc2396E" href="mailto:Simon.Moll@EMEA.NEC.COM"><Simon.Moll@EMEA.NEC.COM></a><br>
<b>Sent:</b> 19 May 2020 15:07<br>
<b>To:</b> Sjoerd Meijer <a class="moz-txt-link-rfc2396E" href="mailto:Sjoerd.Meijer@arm.com">
<Sjoerd.Meijer@arm.com></a><br>
<b>Cc:</b> Roger Ferrer Ibáñez <a class="moz-txt-link-rfc2396E" href="mailto:rofirrim@gmail.com">
<rofirrim@gmail.com></a>; Eli Friedman <a class="moz-txt-link-rfc2396E" href="mailto:efriedma@quicinc.com">
<efriedma@quicinc.com></a>; <a class="moz-txt-link-abbreviated" href="mailto:listmail@philipreames.com">
listmail@philipreames.com</a> <a class="moz-txt-link-rfc2396E" href="mailto:listmail@philipreames.com">
<listmail@philipreames.com></a>; llvm-dev <a class="moz-txt-link-rfc2396E" href="mailto:llvm-dev@lists.llvm.org">
<llvm-dev@lists.llvm.org></a>; Sander De Smalen <a class="moz-txt-link-rfc2396E" href="mailto:Sander.DeSmalen@arm.com">
<Sander.DeSmalen@arm.com></a>; <a class="moz-txt-link-abbreviated" href="mailto:hanna.kruppe@gmail.com">
hanna.kruppe@gmail.com</a> <a class="moz-txt-link-rfc2396E" href="mailto:hanna.kruppe@gmail.com">
<hanna.kruppe@gmail.com></a><br>
<b>Subject:</b> Re: [llvm-dev] LV: predication</font>
<div> </div>
</div>
<div>
<div class="x_moz-cite-prefix">On 5/19/20 12:38 PM, Sjoerd Meijer wrote:<br>
</div>
<blockquote type="cite">
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;
font-size:12pt; color:rgb(0,0,0)">
Hi Simon,</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;
font-size:12pt; color:rgb(0,0,0)">
<br>
</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;
font-size:12pt; color:rgb(0,0,0)">
Thanks for reposting the example, and looking at it more carefully, I think it is very similar to my first proposal. This was met with some resistance here because it dumps loop information in the vector preheader. Doing it this early, we want to emit this
in the vectoriser, puts a restriction on (future) optimisations that transform vector loops to honour/update/support this intrinsic and loop information. In D79100, it is integral part of the vector body and has some semantics (I will update it today), and
thus doesn't have these disadvantages.</div>
</blockquote>
The difference is that in the VP version there is an explicit dependence of every vector operation in the loop to the
<tt>set.num.elements</tt> intrinsic. This dependence is obscured in the hwloop proposals (more on that below).<br>
I understand that you are looking to get hwloops working quickly somehow - but any proposal should be designed in a forward-looking way or we could get stuck in a place it's hard to get out of. I am looking forward to see the semantics for this spelled out.<br>
<br>
<blockquote type="cite">
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;
font-size:12pt; color:rgb(0,0,0)">
Also, the vectoriser isn't using the VP intrinsics yet, so using them is a bridge too far for me at this point. But we should definitely re-evaluate at some point if we should use or transition to them in our backend passes.</div>
</blockquote>
<br>
I'd very much like to see LV use VP intrinsics. I invite everybody to collaborate on VP to make it functional and useful quickly! Specifically, i am hoping we can collaborate on masked reduction intrinsics and implement them in the VP namespace. There is also
the VP expansion pass on Phabricator right now (D78203 - it says 'work-in-progress' in the summary, which probably was a mistake: this is the real thing).<br>
<blockquote type="cite">
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;
font-size:12pt; color:rgb(0,0,0)">
<br>
</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;
font-size:12pt; color:rgb(0,0,0)">
> Are all vector instructions in the hwloop implicitly predicated or only the masked load/store ops?</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;
font-size:12pt; color:rgb(0,0,0)">
<br>
</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;
font-size:12pt; color:rgb(0,0,0)">
In a nutshell, when a vector loop with (explicitly) predicated masked loads/stores hit the backend, we translate the generic intrinsic get.active.mask to a target specific one. All predication remains explicit, and this remains the case. Only at the end, we
use this intrinsic to instruction select a specific variant of the hardwarloop with some implicit predication.</div>
</blockquote>
I do not see an answer to my question here. If the vectorized loop, prepared for hwloop, looks like this:<br>
<br>
<tt> <font size="+1">%m = get.active.mask(..)</font></tt><font size="+1"><tt><br>
</tt><tt> </tt><tt>%v = masked.load ... %m</tt><tt><br>
</tt></font><tt><font size="+1"> %r = sdiv %x, %y</font><br>
<br>
</tt>Will the `sdiv` execute with implicit hwloop predication?<br>
It makes no difference to the semantics of the intrinsic at which point you lower it but how.<br>
<br>
- Simon<tt><br>
<br>
</tt>
<blockquote type="cite">
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;
font-size:12pt; color:rgb(0,0,0)">
<br>
</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;
font-size:12pt; color:rgb(0,0,0)">
Cheers,</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;
font-size:12pt; color:rgb(0,0,0)">
Sjoerd.<br>
</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;
font-size:12pt; color:rgb(0,0,0)">
<br>
</div>
<hr tabindex="-1" style="display:inline-block; width:98%">
<div id="x_divRplyFwdMsg" dir="ltr"><font style="font-size:11pt" face="Calibri, sans-serif" color="#000000"><b>From:</b> Simon Moll
<a class="x_moz-txt-link-rfc2396E" href="mailto:Simon.Moll@EMEA.NEC.COM" moz-do-not-send="true">
<Simon.Moll@EMEA.NEC.COM></a><br>
<b>Sent:</b> 19 May 2020 09:56<br>
<b>To:</b> Sjoerd Meijer <a class="x_moz-txt-link-rfc2396E" href="mailto:Sjoerd.Meijer@arm.com" moz-do-not-send="true">
<Sjoerd.Meijer@arm.com></a><br>
<b>Cc:</b> Roger Ferrer Ibáñez <a class="x_moz-txt-link-rfc2396E" href="mailto:rofirrim@gmail.com" moz-do-not-send="true">
<rofirrim@gmail.com></a>; Eli Friedman <a class="x_moz-txt-link-rfc2396E" href="mailto:efriedma@quicinc.com" moz-do-not-send="true">
<efriedma@quicinc.com></a>; <a class="x_moz-txt-link-abbreviated" href="mailto:listmail@philipreames.com" moz-do-not-send="true">
listmail@philipreames.com</a> <a class="x_moz-txt-link-rfc2396E" href="mailto:listmail@philipreames.com" moz-do-not-send="true">
<listmail@philipreames.com></a>; llvm-dev <a class="x_moz-txt-link-rfc2396E" href="mailto:llvm-dev@lists.llvm.org" moz-do-not-send="true">
<llvm-dev@lists.llvm.org></a>; Sander De Smalen <a class="x_moz-txt-link-rfc2396E" href="mailto:Sander.DeSmalen@arm.com" moz-do-not-send="true">
<Sander.DeSmalen@arm.com></a>; <a class="x_moz-txt-link-abbreviated" href="mailto:hanna.kruppe@gmail.com" moz-do-not-send="true">
hanna.kruppe@gmail.com</a> <a class="x_moz-txt-link-rfc2396E" href="mailto:hanna.kruppe@gmail.com" moz-do-not-send="true">
<hanna.kruppe@gmail.com></a><br>
<b>Subject:</b> Re: [llvm-dev] LV: predication</font>
<div> </div>
</div>
<div>
<div class="x_x_moz-cite-prefix">Hi Sjoerd,<br>
<br>
On 5/18/20 3:43 PM, Sjoerd Meijer wrote:<br>
</div>
<blockquote type="cite">
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;
font-size:12pt; color:rgb(0,0,0)">
> You have similar problems with <a href="https://reviews.llvm.org/D79100" target="_blank" rel="noopener noreferrer" moz-do-not-send="true">
https://reviews.llvm.org/D79100</a><br>
</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;
font-size:12pt; color:rgb(0,0,0)">
<br>
</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;
font-size:12pt; color:rgb(0,0,0)">
The new revision<a href="https://reviews.llvm.org/D79100" target="_blank" rel="noopener noreferrer" id="LPlnk819488" moz-do-not-send="true"> D79100</a> solves your comment 1), and I don't think your comments2) and 3) apply as there are no vendor specific intrinsics
involved at all here. Just to quickly discuss the optimisation pipeline, <a href="https://reviews.llvm.org/D79100" target="_blank" rel="noopener noreferrer" moz-do-not-send="true">
D79100</a> is a small extension for the vectoriser, and nothing here is related to hardware-loops or target specific constructs. The vectoriser tail-folds the loop, and creates masked load/stores; so existing functionality, and nothing has changed here. The
generic hardware loop codegen pass inserts hardware loop intrinsics. Very late in the pipeline, e.g. in the PPC and ARM backends, this is picked and turned into an actual hardwareloop, in our case possibly predicated, or it is reverted.
<br>
</div>
</blockquote>
Thanks for explaining it (possibly once again) I wasn't aware that this will also be used for PPC. Point 3) still stands.<br>
<blockquote type="cite">
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;
font-size:12pt; color:rgb(0,0,0)">
</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;
font-size:12pt; color:rgb(0,0,0)">
<br>
</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;
font-size:12pt; color:rgb(0,0,0)">
> What will you do if there are no masked intrinsics in the hwloop body? <br>
</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;
font-size:12pt; color:rgb(0,0,0)">
<br>
</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;
font-size:12pt; color:rgb(0,0,0)">
Nothing. I.e., it can become a hardware loop, but not one with implicit predication.
<br>
</div>
</blockquote>
Are all vector instructions in the hwloop implicitly predicated or only the masked load/store ops? If not, then the issue is that the predicate parameter of masked load/store basically affects the semantics of all other vector ops in the loop that do not have
an explicit mask parameter:<br>
<br>
<tt> </tt><tt>%v = masked.load ... %m</tt><tt> ; explicit predication - okay<br>
</tt><tt> %r = sdiv %x, %y ; implicit predication by %m for hwloops - unpredicated otherwise</tt><br>
<br>
<blockquote type="cite">
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;
font-size:12pt; color:rgb(0,0,0)">
</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;
font-size:12pt; color:rgb(0,0,0)">
<br>
</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;
font-size:12pt; color:rgb(0,0,0)">
> And i am curious why couldn't you use the %evl parameter of VP intrinsics to get the tail predication you are interested in?<br>
</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;
font-size:12pt; color:rgb(0,0,0)">
<br>
</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;
font-size:12pt; color:rgb(0,0,0)">
In <a href="https://reviews.llvm.org/D79100" target="_blank" rel="noopener noreferrer" id="LPlnk429963" moz-do-not-send="true">
D79100</a>, intrinsic get.active.mask makes the backedge taken count of the scalar loop explicit. I will look again, but I don't think the VP intrinsics were able to provide this. But to be honest, I have no preference at all what this intrinsic is, it is not
relevant, as long as we can make this explicit. <br>
</div>
</blockquote>
VP intrinsics explicitly make every vector instruction in the loop dependent on the '%evl'. You would have :<br>
<br>
<tt> </tt><tt>%v = vp.load ... %evl</tt><tt><br>
</tt><tt> %r = vp.sdiv %x, %y, %evl ; explicitly predicated by the scalar loop trip count<br>
</tt><br>
My previous mail had an example on how %evl could be tied to the scalar trip count. Re-posting that here:<tt><br>
</tt><br>
<tt><tt>vector.preheader:</tt><tt><br>
</tt><tt> %init.evl = i32 llvm.hwloop.set.elements(%n)</tt><tt><br>
</tt><br>
<tt>vector.body:</tt><tt><br>
</tt><tt> %evl = phi 32 [%init.evl, %preheader, %next.evl, vector.body]</tt><tt><br>
</tt><tt> %aval = call @llvm.vp.load(Aptr, .., %evl)</tt><tt><br>
</tt><tt> call @llvm.vp.store(Bptr, %aval, ..., %evl)</tt><tt><br>
</tt><tt> %next.evl = call i32 @llvm.hwloop.decrement(%evl)<br>
<br>
<br>
</tt></tt>- Simon<tt><br>
<br>
</tt>
<blockquote type="cite">
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;
font-size:12pt; color:rgb(0,0,0)">
</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;
font-size:12pt; color:rgb(0,0,0)">
<br>
</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;
font-size:12pt; color:rgb(0,0,0)">
Cheers.<br>
</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;
font-size:12pt; color:rgb(0,0,0)">
<br>
</div>
<hr tabindex="-1" style="display:inline-block; width:98%">
<div id="x_x_divRplyFwdMsg" dir="ltr"><font style="font-size:11pt" face="Calibri, sans-serif" color="#000000"><b>From:</b> Simon Moll
<a class="x_x_moz-txt-link-rfc2396E" href="mailto:Simon.Moll@EMEA.NEC.COM" moz-do-not-send="true">
<Simon.Moll@EMEA.NEC.COM></a><br>
<b>Sent:</b> 18 May 2020 14:11<br>
<b>To:</b> Sjoerd Meijer <a class="x_x_moz-txt-link-rfc2396E" href="mailto:Sjoerd.Meijer@arm.com" moz-do-not-send="true">
<Sjoerd.Meijer@arm.com></a><br>
<b>Cc:</b> Roger Ferrer Ibáñez <a class="x_x_moz-txt-link-rfc2396E" href="mailto:rofirrim@gmail.com" moz-do-not-send="true">
<rofirrim@gmail.com></a>; Eli Friedman <a class="x_x_moz-txt-link-rfc2396E" href="mailto:efriedma@quicinc.com" moz-do-not-send="true">
<efriedma@quicinc.com></a>; <a class="x_x_moz-txt-link-abbreviated" href="mailto:listmail@philipreames.com" moz-do-not-send="true">
listmail@philipreames.com</a> <a class="x_x_moz-txt-link-rfc2396E" href="mailto:listmail@philipreames.com" moz-do-not-send="true">
<listmail@philipreames.com></a>; llvm-dev <a class="x_x_moz-txt-link-rfc2396E" href="mailto:llvm-dev@lists.llvm.org" moz-do-not-send="true">
<llvm-dev@lists.llvm.org></a>; Sander De Smalen <a class="x_x_moz-txt-link-rfc2396E" href="mailto:Sander.DeSmalen@arm.com" moz-do-not-send="true">
<Sander.DeSmalen@arm.com></a>; <a class="x_x_moz-txt-link-abbreviated" href="mailto:hanna.kruppe@gmail.com" moz-do-not-send="true">
hanna.kruppe@gmail.com</a> <a class="x_x_moz-txt-link-rfc2396E" href="mailto:hanna.kruppe@gmail.com" moz-do-not-send="true">
<hanna.kruppe@gmail.com></a><br>
<b>Subject:</b> Re: [llvm-dev] LV: predication</font>
<div> </div>
</div>
<div>
<div class="x_x_x_moz-cite-prefix">On 5/18/20 2:53 PM, Sjoerd Meijer wrote:<br>
</div>
<blockquote type="cite">
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;
font-size:12pt; color:rgb(0,0,0)">
Hi,</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;
font-size:12pt; color:rgb(0,0,0)">
I abandoned that approach and followed Eli's suggestion, see somewhere earlier in this thread, and emit an intrinsic that represents/calculates the active mask. I've just uploaded a new revision for D79100 that implements this.</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;
font-size:12pt; color:rgb(0,0,0)">
Cheers.<br>
</div>
</blockquote>
You have similar problems with <a class="x_x_x_moz-txt-link-freetext" href="https://reviews.llvm.org/D79100" moz-do-not-send="true">
https://reviews.llvm.org/D79100</a><br>
<br>
Since there are no masked operations, except for load/store.. how are LLVM optimizations supposed to know that they must not hoist/sink operations with side-effects out of the hwloop? These operations have an implicit dependence on the iteration variable.<br>
<br>
What will you do if there are no masked intrinsics in the hwloop body? This can happen once you generate vector code beyond trivial loops or have a vector IR generator other than LV.<br>
<br>
And i am curious why couldn't you use the %evl parameter of VP intrinsics to get the tail predication you are interested in?<br>
<br>
- Simon<br>
<br>
<blockquote type="cite">
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;
font-size:12pt; color:rgb(0,0,0)">
</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;
font-size:12pt; color:rgb(0,0,0)">
<br>
</div>
<hr tabindex="-1" style="display:inline-block;
width:98%">
<div id="x_x_x_divRplyFwdMsg" dir="ltr"><font style="font-size:11pt" face="Calibri, sans-serif" color="#000000"><b>From:</b> Simon Moll
<a class="x_x_x_moz-txt-link-rfc2396E" href="mailto:Simon.Moll@EMEA.NEC.COM" moz-do-not-send="true">
<Simon.Moll@EMEA.NEC.COM></a><br>
<b>Sent:</b> 18 May 2020 13:32<br>
<b>To:</b> Sjoerd Meijer <a class="x_x_x_moz-txt-link-rfc2396E" href="mailto:Sjoerd.Meijer@arm.com" moz-do-not-send="true">
<Sjoerd.Meijer@arm.com></a><br>
<b>Cc:</b> Roger Ferrer Ibáñez <a class="x_x_x_moz-txt-link-rfc2396E" href="mailto:rofirrim@gmail.com" moz-do-not-send="true">
<rofirrim@gmail.com></a>; Eli Friedman <a class="x_x_x_moz-txt-link-rfc2396E" href="mailto:efriedma@quicinc.com" moz-do-not-send="true">
<efriedma@quicinc.com></a>; <a class="x_x_x_moz-txt-link-abbreviated" href="mailto:listmail@philipreames.com" moz-do-not-send="true">
listmail@philipreames.com</a> <a class="x_x_x_moz-txt-link-rfc2396E" href="mailto:listmail@philipreames.com" moz-do-not-send="true">
<listmail@philipreames.com></a>; llvm-dev <a class="x_x_x_moz-txt-link-rfc2396E" href="mailto:llvm-dev@lists.llvm.org" moz-do-not-send="true">
<llvm-dev@lists.llvm.org></a>; Sander De Smalen <a class="x_x_x_moz-txt-link-rfc2396E" href="mailto:Sander.DeSmalen@arm.com" moz-do-not-send="true">
<Sander.DeSmalen@arm.com></a>; <a class="x_x_x_moz-txt-link-abbreviated" href="mailto:hanna.kruppe@gmail.com" moz-do-not-send="true">
hanna.kruppe@gmail.com</a> <a class="x_x_x_moz-txt-link-rfc2396E" href="mailto:hanna.kruppe@gmail.com" moz-do-not-send="true">
<hanna.kruppe@gmail.com></a><br>
<b>Subject:</b> Re: [llvm-dev] LV: predication</font>
<div> </div>
</div>
<div>
<div class="x_x_x_x_moz-cite-prefix">On 5/5/20 12:07 AM, Sjoerd Meijer via llvm-dev wrote:<br>
</div>
<blockquote type="cite">
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;
font-size:12pt; color:rgb(0,0,0)">
what we would like to generate is a vector loop with implicit predication, which works by setting up the the number of elements processed by the loop:<br>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;
font-size:12pt">
<br>
</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;
font-size:12pt">
hwloop 10<br>
</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;
font-size:12pt">
[i:4] = b[i:4] + c[i:4]</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;
font-size:12pt">
<br>
</div>
</div>
</blockquote>
Why couldn't you use VP intrinsics and scalable types for this?<br>
<br>
<tt> %bval = <4 x vscale x double> call @vp.load(..., /* %evl */ 10)</tt><tt><br>
</tt><tt> %cval = <4 x vscale x double> call @vp.load(..., /* %evl */ 10)</tt><tt><br>
</tt><tt> %sum = <4 x vscale x double> fadd %bval, %cval</tt><tt><br>
</tt><tt> store [..]</tt><br>
<br>
I see three issues with the llvm.set.loop.elements approach:<br>
1) It is conceptually broken: as others have pointed out, optimization can move the intrinsic around since the intrinsic doesn't have any dependencies that would naturally keep it in place.<br>
2) The whole proposed set of intrinsics is vendor specific: this causes fragmentation and i don't see why we would want to emit vendor-specific intrinsics in a generic optimization pass. Soon, we would see reports a la "your optimization caused regressions
for MVE - add a check that the transformation must not touch llvm.set.loop.* or llvm.active.mask intrinsics when compiling for MVE..". I doubt that you would tolerate when that intrinsic were some removed in performance-critical code that would then remain
scalar as a result.. so, i do not see the "beauty of the approach".<br>
3) We need a reliable solution to properly support vector ISA such as RISC-V V extension and SX-Aurora and also MVE.. i don't see that reliability in this proposal.<br>
<br>
If for whatever reason, the above does not work and seems to far away from your proposal, here is another idea to make more explicit hwloops work with the VP intrinsics - in a way that does not break with optimizations:<br>
<br>
<tt>vector.preheader:</tt><tt><br>
</tt><tt> %evl = i32 llvm.hwloop.set.elements(%n)</tt><tt><br>
</tt><br>
<tt>vector.body:</tt><tt><br>
</tt><tt> %lastevl = phi 32 [%evl, %preheader, %next.evl, vector.body]</tt><tt><br>
</tt><tt> %aval = call @llvm.vp.load(Aptr, .., %evl)</tt><tt><br>
</tt><tt> call @llvm.vp.store(Bptr, %aval, ..., %evl)</tt><tt><br>
</tt><tt> %next.evl = call i32 @llvm.hwloop.decrement(%evl)</tt><br>
<br>
Note that the way VP intrinsics are designed, it is not possible to break this code by hoisting the VP calls out of the loop: passing "%evl >= the operation's vector size" consitutes UB (see
<a class="x_x_x_x_moz-txt-link-freetext" href="https://llvm.org/docs/LangRef.html#vector-predication-intrinsics" moz-do-not-send="true">
https://llvm.org/docs/LangRef.html#vector-predication-intrinsics</a>). We can use attributes to do the same for sinking (eg don't move VP across hwloop.decrement).<br>
<br>
- Simon<br>
</div>
<br>
<br>
</blockquote>
<br>
</div>
</blockquote>
</div>
</blockquote>
</div>
</blockquote>
<br>
</body>
</html>