<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Oct 3, 2017 at 10:08 AM, Hal Finkel <span dir="ltr"><<a href="mailto:hfinkel@anl.gov" target="_blank">hfinkel@anl.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF"><span class="gmail-">
<p><br>
</p>
<div class="gmail-m_-531130806322538295moz-cite-prefix">On 10/03/2017 05:26 AM, Ristow, Warren
wrote:<br>
</div>
<blockquote type="cite">
<div class="gmail-m_-531130806322538295WordSection1">
<div>
<p class="MsoNormal"><span style="font-size:11pt;font-family:"Calibri","sans-serif";color:rgb(68,84,106)">>
I agree that using SubclassOptionalData is going to be
problematic when we run out of bits. ...<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:"Calibri","sans-serif";color:rgb(68,84,106)"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:"Calibri","sans-serif";color:rgb(68,84,106)">I
don't have a good view of the big-picture here (in terms
of the cost of size and speed of the metadata approach, vs
a member of Instruction, vs something else).<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:"Calibri","sans-serif";color:rgb(68,84,106)"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:"Calibri","sans-serif";color:rgb(68,84,106)">We
could tackle this problem now, or defer it hoping that
we're not going to want to add more flags for finer
granularity control of fast-math transformations in the
future. It seems the general sense is that we should
tackle it now.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:"Calibri","sans-serif";color:rgb(68,84,106)">Sanjay
and Hal, is that what you're view is?</span></p>
</div>
</div>
</blockquote>
<br></span>
I think that it might be a good idea, but I don't have an opinion on
ordering. They should be separate patches if possible (and, if it is
not possible because we've run out of bits, then obviously the
decision has been made for us).<span class="gmail-HOEnZb"><font color="#888888"><br>
<br></font></span></div></blockquote><div><br></div><div>Yes, it seems like we're going to hit that wall sooner or later, so I'd try to get that part done first since that should have no visible effect on the final codegen.<br></div><div><br></div><div>I have no sense of what the fastest implementation would be or how anyone would know without just trying something and timing it.<br></div><div><br></div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div bgcolor="#FFFFFF"><span class="gmail-HOEnZb"><font color="#888888">
-Hal</font></span><div><div class="gmail-h5"><br>
<br>
<blockquote type="cite">
<div class="gmail-m_-531130806322538295WordSection1">
<div>
<p class="MsoNormal"><span style="font-size:11pt;font-family:"Calibri","sans-serif";color:rgb(68,84,106)"><u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:"Calibri","sans-serif";color:rgb(68,84,106)"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:"Calibri","sans-serif";color:rgb(68,84,106)">-Warren</span><span style="font-size:11pt;font-family:"Calibri","sans-serif";color:rgb(68,84,106)"><u></u><u></u></span></p>
</div>
<p class="MsoNormal"><span style="font-size:11pt;font-family:"Calibri","sans-serif";color:rgb(68,84,106)"><u></u> <u></u></span></p>
<div>
<div style="border-width:1pt medium medium;border-style:solid none none;border-color:rgb(181,196,223) currentcolor currentcolor;padding:3pt 0in 0in">
<p class="MsoNormal"><b><span style="font-size:10pt;font-family:"Tahoma","sans-serif";color:windowtext">From:</span></b><span style="font-size:10pt;font-family:"Tahoma","sans-serif";color:windowtext">
Hal Finkel [<a class="gmail-m_-531130806322538295moz-txt-link-freetext" href="mailto:hfinkel@anl.gov" target="_blank">mailto:hfinkel@anl.gov</a>]
<br>
<b>Sent:</b> Tuesday, October 3, 2017 1:49 AM<br>
<b>To:</b> Sanjay Patel; Ristow, Warren<br>
<b>Cc:</b> <a class="gmail-m_-531130806322538295moz-txt-link-abbreviated" href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<b>Subject:</b> Re: [llvm-dev] Trouble when suppressing
a portion of fast-math-transformations<u></u><u></u></span></p>
</div>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<p><u></u> <u></u></p>
<div>
<p class="MsoNormal">On 10/01/2017 06:05 PM, Sanjay Patel
wrote:<u></u><u></u></p>
</div>
<blockquote style="margin-top:5pt;margin-bottom:5pt">
<div>
<div>
<p class="MsoNormal">Are we confident that we just need
those 7 bits to represent all of the relaxed FP states
that we need/want to support?
<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12pt">I'm
asking because FMF in IR is currently mapped onto the
SubclassOptionalData of Value...and we have exactly 7
bits there. :)<u></u><u></u></p>
</div>
<p class="MsoNormal">If we're redoing the definitions, I'm
wondering if we can share the struct with the backend's
SDNodeFlags, but that already has one extra bit for vector
reduction. Should we give up on SubclassOptionalData for
FMF? We have a MD_fpmath enum value for metadata, so we
could move things over there?<u></u><u></u></p>
</div>
</blockquote>
<p class="MsoNormal"><br>
I agree that using SubclassOptionalData is going to be
problematic when we run out of bits. As I recall, the reason
that we didn't use metadata in the first place was because
metadata is (generically) expensive. This case is very much
like the case of debug info: in some modes, we add the
debugging metadata to nearly every instruction. We use
metadata for debug locations, syntactically, but we actually
have a DebugLoc in each instruction that's used for the
underlying representation. Here we'd have a similar problem:
in some modes, we'd add this metadata to a large subset of all
instructions. That could measurably slow down the optimizer.
We may need to find some other place to put the data (e.g., an
actual member variable of Instruction or more tail-allocated
data in places)<br>
<br>
-Hal<br>
<br>
<br>
<u></u><u></u></p>
<div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<p class="MsoNormal">On Fri, Sep 29, 2017 at 8:16 PM,
Ristow, Warren via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>>
wrote:<u></u><u></u></p>
<p class="MsoNormal">Hi Hal,<br>
<br>
>> 4. To fix this, I think that additional
fast-math-flags are likely<br>
>> needed in the IR. Instead of the following set:<br>
>><br>
>> 'nnan' + 'ninf' + 'nsz' + 'arcp' + 'contract'<br>
>><br>
>> something like this:<br>
>><br>
>> 'reassoc' + 'libm' + 'nnan' + 'ninf' + 'nsz' +
'arcp' + 'contract'<br>
>><br>
>> would be more useful. Related to this, the
current 'fast' flag which acts<br>
>> as an umbrella (enabling 'nnan' + 'ninf' + 'nsz'
+ 'arcp' + 'contract') may<br>
>> not be needed. A discussion on this point was
raised last November on the<br>
>> mailing list:<br>
>><br>
>> <a href="http://lists.llvm.org/pipermail/llvm-dev/2016-November/107104.html" target="_blank">
http://lists.llvm.org/<wbr>pipermail/llvm-dev/2016-<wbr>November/107104.html</a><br>
><br>
> I agree. I'm happy to help review the patches. It
will be best to have<br>
> only the finer-grained flags where there's no "fast"
flag that implies<br>
> all of the others.<br>
<br>
Thanks for the quick response, and for the willingness to
review. I won't let<br>
this languish so long, like the post from last November.<br>
<br>
Happy to hear that you feel it's best not to have the
umbrella "fast" flag.<br>
<br>
Thanks again,<u></u><u></u></p>
<div>
<div>
<p class="MsoNormal">-Warren<br>
______________________________<wbr>_________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-dev</a><u></u><u></u></p>
</div>
</div>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<p class="MsoNormal"><br>
<br>
<u></u><u></u></p>
<pre>-- <u></u><u></u></pre>
<pre>Hal Finkel<u></u><u></u></pre>
<pre>Lead, Compiler Technology and Programming Languages<u></u><u></u></pre>
<pre>Leadership Computing Facility<u></u><u></u></pre>
<pre>Argonne National Laboratory<u></u><u></u></pre>
</div>
</blockquote>
<br>
<pre class="gmail-m_-531130806322538295moz-signature" cols="72">--
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory</pre>
</div></div></div>
</blockquote></div><br></div></div>