<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 12 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
{font-family:Consolas;
panose-1:2 11 6 9 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";
color:black;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p
{mso-style-priority:99;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:12.0pt;
font-family:"Times New Roman","serif";
color:black;}
pre
{mso-style-priority:99;
mso-style-link:"HTML Preformatted Char";
margin:0in;
margin-bottom:.0001pt;
font-size:10.0pt;
font-family:"Courier New";
color:black;}
span.HTMLPreformattedChar
{mso-style-name:"HTML Preformatted Char";
mso-style-priority:99;
mso-style-link:"HTML Preformatted";
font-family:Consolas;
color:black;}
span.EmailStyle20
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#44546A;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body bgcolor="white" lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#44546A">> I agree that using SubclassOptionalData is going to be problematic when we run out of bits. ...<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#44546A"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#44546A">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).<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#44546A"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#44546A">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.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#44546A">Sanjay and Hal, is that what you're view is?<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#44546A"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#44546A">-Warren</span><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#44546A"><o:p></o:p></span></p>
</div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#44546A"><o:p> </o:p></span></p>
<div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif";color:windowtext">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif";color:windowtext"> Hal Finkel [mailto:hfinkel@anl.gov]
<br>
<b>Sent:</b> Tuesday, October 3, 2017 1:49 AM<br>
<b>To:</b> Sanjay Patel; Ristow, Warren<br>
<b>Cc:</b> llvm-dev@lists.llvm.org<br>
<b>Subject:</b> Re: [llvm-dev] Trouble when suppressing a portion of fast-math-transformations<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p><o:p> </o:p></p>
<div>
<p class="MsoNormal">On 10/01/2017 06:05 PM, Sanjay Patel wrote:<o:p></o:p></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<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?
<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt">I'm asking because FMF in IR is currently mapped onto the SubclassOptionalData of Value...and we have exactly 7 bits there. :)<o:p></o:p></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?<o:p></o:p></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>
<o:p></o:p></p>
<div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></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:<o:p></o:p></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/pipermail/llvm-dev/2016-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,<o:p></o:p></p>
<div>
<div>
<p class="MsoNormal">-Warren<br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org">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/mailman/listinfo/llvm-dev</a><o:p></o:p></p>
</div>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<p class="MsoNormal"><br>
<br>
<o:p></o:p></p>
<pre>-- <o:p></o:p></pre>
<pre>Hal Finkel<o:p></o:p></pre>
<pre>Lead, Compiler Technology and Programming Languages<o:p></o:p></pre>
<pre>Leadership Computing Facility<o:p></o:p></pre>
<pre>Argonne National Laboratory<o:p></o:p></pre>
</div>
</body>
</html>