<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, May 16, 2017 at 12:18 PM, Friedman, Eli <span dir="ltr"><<a href="mailto:efriedma@codeaurora.org" target="_blank">efriedma@codeaurora.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF"><span>
<div class="m_1485977280468077149m_-7969451576088178800moz-cite-prefix">On 5/16/2017 6:30 AM, Sanjay Patel
wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">Thanks for posting this question, Julia.<br>
<br>
I had a similar question about a signed min/max variant here:<br>
<a href="http://lists.llvm.org/pipermail/llvm-dev/2016-November/106868.html" target="_blank">http://lists.llvm.org/pipermai<wbr>l/llvm-dev/2016-November/<wbr>106868.html</a><br>
<br>
The 2nd version in each case contains a canonical max/min
representation in IR, and this could enable more IR analysis. <br>
A secondary advantage is that the backend recognizes the max/min
in the second IR form when creating DAG nodes, <br>
and this directly affects isel for many targets.<br>
</div>
</blockquote>
<br></span>
This seems important. And pattern-matching max(x,y)-y to a
saturating subtract seems easy in the backend.<span><br>
<br>
<blockquote type="cite">
<div dir="ltr">A possibly important difference between the earlier
example and the current unsigned case: <br>
is a select with a zero constant operand easier to reason about
in IR than the canonical min/max?<br>
</div>
</blockquote>
<br></span>
It might be in some cases... maybe? I mean, it might be easier to
analyze in ComputeMaskedBits or something, but we don't really do
much to optimize selects involving zero.<br></div></blockquote><div><br></div><div>Because of my CPU upbringing, I always see this:<br></div><div>select A, B, 0<br><br></div><div>as:<br></div><div>and (sext A), B<br><br></div><div>Any chance of control-flow is bad!<br>...but now I know that's wrong for IR. :) <br></div><div><br></div><div>So forming the min/max sounds like the right answer to me.<br><br></div><div>Note that we don't actually canonicalize the signed min/max cases from the earlier thread yet. We detect those in value tracking, and that was good enough to produce the ideal backend results, but I haven't gotten back to doing the transform in IR.<br></div><div><br></div><div><br><br><br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div text="#000000" bgcolor="#FFFFFF">
-Eli<br>
<br>
<blockquote type="cite">
<div class="gmail_extra">
<div class="gmail_quote"><span>On Tue, May 16, 2017 at 5:30 AM, Koval,
Julia <span dir="ltr"><<a href="mailto:julia.koval@intel.com" target="_blank">julia.koval@intel.com</a>></span>
wrote:<br>
</span><span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
(1.16)<br>
%cmp = icmp ugt i16 %x, %y<br>
%sub2 = sub i16 %y, %x<br>
%res = select i1 %cmp, i16 0, i16 %sub2<br>
<br>
or<br>
<br>
(2.16)<br>
%cmp = icmp ugt i16 %x, %y<br>
%sel = select i1 %cmp, i16 %x, i16 %y<br>
%sub = sub i16 %sel, %x<br>
<br>
Which of these versions is canonical? I think first version
is better, because it can be converted to unsigned
saturation instruction(i.e. PSUBUS), using existing backend
code.<br>
</blockquote>
</span></div>
<br><span class="m_1485977280468077149HOEnZb"><font color="#888888">
</font></span></div><span class="m_1485977280468077149HOEnZb"><font color="#888888">
</font></span></blockquote><span class="m_1485977280468077149HOEnZb"><font color="#888888">
<p><br>
</p>
<pre class="m_1485977280468077149m_-7969451576088178800moz-signature" cols="72">--
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project</pre>
</font></span></div>
</blockquote></div><br></div></div>