<html><head><style type='text/css'>p { margin: 0; }</style></head><body><div style='font-family: arial,helvetica,sans-serif; font-size: 10pt; color: #000000'><br><hr id="zwchr"><blockquote style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px; color: rgb(0, 0, 0); font-weight: normal; font-style: normal; text-decoration: none; font-family: Helvetica,Arial,sans-serif; font-size: 12pt;"><b>From: </b>"David L via llvm-dev Kreitzer" <llvm-dev@lists.llvm.org><br><b>To: </b>"Warren Ristow" <warren.ristow@sony.com>, "mehdi amini" <mehdi.amini@apple.com><br><b>Cc: </b>llvm-dev@lists.llvm.org<br><b>Sent: </b>Friday, November 18, 2016 3:39:33 PM<br><b>Subject: </b>Re: [llvm-dev] RFC: Consider changing the semantics of 'fast' flag implying all fast-math-flags<br><br>
<style><!--
@font-face
{font-family:Helvetica;
panose-1:2 11 6 4 2 2 2 2 2 4;}
@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:Verdana;
panose-1:2 11 6 4 3 5 4 4 2 4;}
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman",serif;}
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.MsoPlainText, li.MsoPlainText, div.MsoPlainText
{mso-style-priority:99;
mso-style-link:"Plain Text Char";
margin:0in;
margin-bottom:.0001pt;
font-size:10.0pt;
font-family:"Courier New";}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman",serif;}
span.apple-converted-space
{mso-style-name:apple-converted-space;}
span.EmailStyle19
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:#1F497D;}
span.EmailStyle20
{mso-style-type:personal-reply;
font-family:"Verdana",sans-serif;
color:windowtext;
font-weight:normal;
font-style:normal;
text-decoration:none none;}
span.PlainTextChar
{mso-style-name:"Plain Text Char";
mso-style-priority:99;
mso-style-link:"Plain Text";
font-family:"Courier New";}
.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>
<div class="WordSection1">
<p class="MsoPlainText">I just read through this thread, and I did not see a good definition of what</p>
<p class="MsoPlainText">exactly "fast + no-arcp" would mean. Clearly (1) would be disallowed, but what</p>
<p class="MsoPlainText">about the others?</p>
<p class="MsoPlainText"> </p>
<p class="MsoPlainText"> (1) X / Y --> X * (1.0 / Y)</p>
<p class="MsoPlainText"> (2) (X * Y) / Z --> (X / Z) * Y</p>
<p class="MsoPlainText"> (3) (X / Z) * Y --> X * (Y / Z)</p>
<p class="MsoPlainText"> (4) (X / Y) / Z --> X / (Y * Z)</p>
<p class="MsoPlainText"> etc.</p>
<p class="MsoPlainText"> </p>
<p class="MsoPlainText">It is easy to write a unit test for each of (1)-(4) showing that gcc6.2 will</p>
<p class="MsoPlainText">apply the transform under "-ffast-math" but not under</p>
<p class="MsoPlainText">"-ffast-math -fno-reciprocal-math". (It is also easy to write unit tests where</p>
<p class="MsoPlainText">gcc6.2 will perform these transforms in spite of -fno-reciprocal-math, but I</p>
<p id="DWT891" class="MsoPlainText">assume those would be considered bugs.)</p></div></blockquote>Interesting question. I think this is right. (1) must be disallowed (that *is* the exact transformation after which the flag is named). Disallowing (2-4) makes sense to me also in that configuration. The basic idea being that, with -fno-reciprocal-math, we never make an algebraic change to the numerator or denominator of a division operation.<br><blockquote style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px; color: rgb(0, 0, 0); font-weight: normal; font-style: normal; text-decoration: none; font-family: Helvetica,Arial,sans-serif; font-size: 12pt;"><div class="WordSection1"><p class="MsoPlainText"></p>
<p class="MsoPlainText"> </p>
<p class="MsoPlainText">I trust the intent is to update the language reference such that it is easy to</p>
<p id="DWT890" class="MsoPlainText">reason about the correctness of these and other division-related transforms?</p></div></blockquote>Yes, we should definitely make sure that the language reference is clear.<br><br> -Hal<br><blockquote style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px; color: rgb(0, 0, 0); font-weight: normal; font-style: normal; text-decoration: none; font-family: Helvetica,Arial,sans-serif; font-size: 12pt;"><div class="WordSection1"><p class="MsoPlainText"></p>
<p class="MsoPlainText"> </p>
<p class="MsoPlainText">Thanks,</p>
<p class="MsoPlainText">- Dave</p>
<p class="MsoNormal"><span style="font-size: 10pt; font-family: "Verdana",sans-serif;"> </span></p>
<p class="MsoNormal"><a name="_MailEndCompose"><span style="font-size: 10pt; font-family: "Verdana",sans-serif;"> </span></a></p>
<div>
<div style="border-right: medium none; border-width: 1pt medium medium; border-style: solid none none; border-color: rgb(225, 225, 225) -moz-use-text-color -moz-use-text-color; padding: 3pt 0in 0in;">
<p class="MsoNormal"><a name="_____replyseparator"></a><b><span style="font-size: 11pt; font-family: "Calibri",sans-serif;">From:</span></b><span style="font-size: 11pt; font-family: "Calibri",sans-serif;"> llvm-dev [mailto:llvm-dev-bounces@lists.llvm.org]
<b>On Behalf Of </b>Ristow, Warren via llvm-dev<br>
<b>Sent:</b> Thursday, November 17, 2016 5:24 PM<br>
<b>To:</b> mehdi.amini@apple.com<br>
<b>Cc:</b> llvm-dev@lists.llvm.org<br>
<b>Subject:</b> Re: [llvm-dev] RFC: Consider changing the semantics of 'fast' flag implying all fast-math-flags</span></p>
</div>
</div>
<p class="MsoNormal"> </p>
<p class="MsoNormal"><span style="font-size: 11pt; font-family: "Calibri",sans-serif; color: rgb(31, 73, 125);">Thanks for all that. I think we’re more in agreement here than it may have appeared initially.</span></p>
<p class="MsoNormal"><span style="font-size: 11pt; font-family: "Calibri",sans-serif; color: rgb(31, 73, 125);"> </span></p>
<p class="MsoNormal">> So let’s just fix it!</p>
<p class="MsoNormal"><span style="font-size: 11pt; font-family: "Calibri",sans-serif; color: rgb(31, 73, 125);"> </span></p>
<p class="MsoNormal"><span style="font-size: 11pt; font-family: "Calibri",sans-serif; color: rgb(31, 73, 125);">Sounds good!</span></p>
<p class="MsoNormal"><span style="font-size: 11pt; font-family: "Calibri",sans-serif; color: rgb(31, 73, 125);"> </span></p>
<p class="MsoNormal"><span style="font-size: 11pt; font-family: "Calibri",sans-serif; color: rgb(31, 73, 125);">I have some other things on my plate at the moment, so I doubt I’ll get to working on this until after Thanksgiving (I don’t won’t my lack of activity to be interpreted
as a loss of interest on my part to get this done).</span></p>
<p class="MsoNormal"><span style="font-size: 11pt; font-family: "Calibri",sans-serif; color: rgb(31, 73, 125);"> </span></p>
<p class="MsoNormal"><span style="font-size: 11pt; font-family: "Calibri",sans-serif; color: rgb(31, 73, 125);">Before work can be done to fix it, the details of precisely what changes we want to make in the fast-math-flags IR needs to be decided. There has been some discussion
in this thread on that point (‘aggr’, ‘reassoc’ + ‘libm’, something else?), but no clear spec. I’d be happy to propose something concrete, and I’d fully expect that it would evolve a bit after feedback. I’m also happy for others to propose specifics. In
any case, I won’t work on taking this further until sometime after Thanksgiving.</span></p>
<p class="MsoNormal"><span style="font-size: 11pt; font-family: "Calibri",sans-serif; color: rgb(31, 73, 125);"> </span></p>
<p class="MsoNormal"><span style="font-size: 11pt; font-family: "Calibri",sans-serif; color: rgb(31, 73, 125);">-Warren</span></p>
<p class="MsoNormal"><span style="font-size: 11pt; font-family: "Calibri",sans-serif; color: rgb(31, 73, 125);"> </span></p>
<div>
<div style="border-right: medium none; border-width: 1pt medium medium; border-style: solid none none; border-color: rgb(225, 225, 225) -moz-use-text-color -moz-use-text-color; padding: 3pt 0in 0in;">
<p class="MsoNormal"><b><span style="font-size: 11pt; font-family: "Calibri",sans-serif;">From:</span></b><span style="font-size: 11pt; font-family: "Calibri",sans-serif;">
<a href="mailto:mehdi.amini@apple.com" target="_blank">mehdi.amini@apple.com</a> [<a href="mailto:mehdi.amini@apple.com" target="_blank">mailto:mehdi.amini@apple.com</a>]
<br>
<b>Sent:</b> Thursday, November 17, 2016 2:03 PM<br>
<b>To:</b> Ristow, Warren <<a href="mailto:warren.ristow@sony.com" target="_blank">warren.ristow@sony.com</a>><br>
<b>Cc:</b> <a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<b>Subject:</b> Re: [llvm-dev] RFC: Consider changing the semantics of 'fast' flag implying all fast-math-flags</span></p>
</div>
</div>
<p class="MsoNormal"> </p>
<p class="MsoNormal"> </p>
<div>
<blockquote style="margin-top: 5pt; margin-bottom: 5pt;">
<div>
<p class="MsoNormal">On Nov 17, 2016, at 1:44 PM, Mehdi Amini via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:</p>
</div>
<p class="MsoNormal"> </p>
<div>
<blockquote style="margin-top: 5pt; margin-bottom: 5pt; text-align: start; word-spacing: 0px;">
<p class="MsoNormal" style="margin-bottom: 12pt;"><span style="font-size: 9pt; font-family: "Helvetica",sans-serif;"><br>
On Nov 17, 2016, at 1:24 PM, Ristow, Warren <<a href="mailto:warren.ristow@sony.com" target="_blank">warren.ristow@sony.com</a>> wrote:<br>
<br>
On the plus side, I'm glad to see the conclusions of the last couple of posts.<br>
<br>
>From Mehdi:<br>
<br>
</span></p>
<blockquote style="margin-top: 5pt; margin-bottom: 5pt;">
<p class="MsoNormal"><span style="font-size: 9pt; font-family: "Helvetica",sans-serif;">Hope this clarify where I see the direction going, and even if you don’t agree with my<br>
reasoning, the conclusion should be satisfactory on your side :)</span></p>
</blockquote>
<p class="MsoNormal" style="margin-bottom: 12pt;"><span style="font-size: 9pt; font-family: "Helvetica",sans-serif;"><br>
I'd say that summarizes my thoughts on this well.<br>
<br>
And from Nicolai:<br>
<br>
</span></p>
<blockquote style="margin-top: 5pt; margin-bottom: 5pt;">
<p class="MsoNormal"><span style="font-size: 9pt; font-family: "Helvetica",sans-serif;">Right. I'm not fundamentally opposed to having these flags, ...</span></p>
</blockquote>
<p class="MsoNormal"><span style="font-size: 9pt; font-family: "Helvetica",sans-serif;"><br>
I do agree with much of what you both say, but definitely not all of it. The philosophy of not providing what a customer requests and instead guiding them to a better alternative is something I agree with -- we don't just give them a pony. And I agree *strongly*
that just because a program gets the answer a user wants with GCC (using fast-math) and we get an answer they view as "wrong", doesn't mean it's a bug of ours and that we need to change to get the same answer as GCC. That's not what our goal of GCC compatibility
means to me.<br>
<br>
But we do have a switch '-fno-reciprocal-math' that we accept, and even process/implement to some extent. But that implementation has a bug. Fixing that bug so that when a user says '-ffast-math -fno-reciprocal-math', we enable the fast-math transformations
but explicitly disable the reciprocal transformations is, in my view, the right thing to do. Simply, that is a bug that we ought to fix -- unless we agree to abandon support of '-fno-reciprocal-math', which I think isn't under consideration at this stage.
And FTR, I'd oppose that, not surprisingly. :)</span></p>
</blockquote>
<p class="MsoNormal" style="margin-bottom: 12pt;"><span style="font-size: 9pt; font-family: "Helvetica",sans-serif;"><br>
<br>
<br>
</span></p>
<blockquote style="margin-top: 5pt; margin-bottom: 5pt;">
<p class="MsoNormal"><span style="font-size: 9pt; font-family: "Helvetica",sans-serif;"><br>
I'm not at all trying to justify the "pony" use-case from this customer, but if we provide '-fno-reciprocal-math', I think we ought to fix bugs we find in our implementation of it. Fixing that bug doesn't guarantee we'll then get the same answers as GCC does
on every program when compiled with '-ffast-math -fno-reciprocal-math', but IMO that isn't required for us to describe our behavior as "GCC compatibility" in this respect.<br>
<br>
Fast-math is "unusual", in that the user is explicitly opening the door to allowing us to do non-compliant transformations. As compared with GCC, our implementation can have a subset or a superset of these non-compliant transformations, and we can still call
that "GCC compatibility". As an analogous "not unusual" feature, both we and GCC do type based alias analysis. It's a perfectly standard-compliant thing to do optimizations based on conclusions from the tbaa. We both support the switch '-f[no-]strict-aliasing'
to control this (and we both enable it by default). Referring to this as "GCC compatibility" is perfectly legitimate, in my view. But if a user program has an aliasing bug in it, and our tbaa directs us to aggressively optimize it, whereas GCC's doesn't
(and so the user gets the answer they wanted with GCC, but not with us), this does not mean we have a bug, or that saying we're GCC compatible in terms of '-f[no-]strict-aliasing' is a "lie". We can do a superset or subset of the optimizations that GCC does
in terms of alias analysis, and we can quite reasonably describe us a GCC compatible in terms of us providing this capability. A user insisting we have a bug in this tbaa situation is analogous to your "pony" request about "float test_div(float a, float b)
{ return a/b; }". And (unrelated to Clang/LLVM) I've had this sort of objection from users in tbaa situations in the past, where I've had to defend my point that just because GCC didn't optimize it as aggressively as the compiler I was providing, it wasn't
a bug in our compiler. So I'm all for not giving everyone a pony.<br>
<br>
But irrespective of how silly a test-case it may be to do:<br>
<br>
{<br>
float x = a / c;<br>
float y = b / c;<br>
<br>
if (y == 1.0f) {<br>
// do some processing for when 'b' and 'c' are equal<br>
} else {<br>
// do other processing<br>
}<br>
<br>
use(x, y);<br>
}<br>
<br>
I cannot in good conscience tell the customer that it's OK for us to do:<br>
<br>
float tmp = 1.0f / c;<br>
float x = a * tmp;<br>
float y = b * tmp;<br>
<br>
when they specified '-ffast-math -fno-reciprocal-math'. They can rightfully come back and say "what do you mean by '-fno-reciprocal-math'?" I have to call that a compiler-bug.</span></p>
</blockquote>
<p class="MsoNormal"><span style="font-size: 9pt; font-family: "Helvetica",sans-serif;"><br>
I agree with all you wrote above :)<br>
But I’d add that a legitimate fix could be for the clang driver to issue an error (or a warning) saying “-fno-reciprocal-math” isn’t compatible with -ffast-math, disabling -fxxxxxx” (with xxxxx being one or the other ;))</span></p>
</div>
</blockquote>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal">I don’t want to add confusion, I feel I’m doing a bad job here somehow: I’m not saying we *should* do this (rejecting in the driver). So let’s just fix it!</p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal">— </p>
</div>
<div>
<p class="MsoNormal">Mehdi</p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<blockquote style="margin-top: 5pt; margin-bottom: 5pt; text-align: start; word-spacing: 0px;">
<div>
<blockquote style="margin-top: 5pt; margin-bottom: 5pt;">
<p class="MsoNormal"><span style="font-size: 9pt; font-family: "Helvetica",sans-serif;"> </span></p>
</blockquote>
<blockquote style="margin-top: 5pt; margin-bottom: 5pt; text-align: start; word-spacing: 0px;">
<p class="MsoNormal" style="margin-bottom: 12pt;"><span style="font-size: 9pt; font-family: "Helvetica",sans-serif;"><br>
-----Original Message-----<br>
From: Nicolai Hähnle [<a href="mailto:nhaehnle@gmail.com" target="_blank">mailto:nhaehnle@gmail.com</a>]<span class="apple-converted-space"> </span><br>
Sent: Thursday, November 17, 2016 12:36 PM<br>
To: Kaylor, Andrew <<a href="mailto:andrew.kaylor@intel.com" target="_blank">andrew.kaylor@intel.com</a>>; Ristow, Warren <<a href="mailto:warren.ristow@sony.com" target="_blank">warren.ristow@sony.com</a>>;
<a href="mailto:mehdi.amini@apple.com" target="_blank">mehdi.amini@apple.com</a><br>
Cc: <a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
Subject: Re: [llvm-dev] RFC: Consider changing the semantics of 'fast' flag implying all fast-math-flags<br>
<br>
On 17.11.2016 19:54, Kaylor, Andrew wrote:</span></p>
<blockquote style="margin-top: 5pt; margin-bottom: 5pt;">
<blockquote style="margin-top: 5pt; margin-bottom: 5pt;">
<p class="MsoNormal"><span style="font-size: 9pt; font-family: "Helvetica",sans-serif;">All that said, I think we (the company I work for, Sony) will have to<span class="apple-converted-space"> </span><br>
implement support for these switches. It comes down to GCC has these<span class="apple-converted-space"> </span><br>
switches (e.g., -fno-reciprocal-math and -fno-associative-math), and they do suppress the transformations for our customers.<br>
They switch to Clang/LLVM, they use the same switches, and it doesn't<span class="apple-converted-space"> </span><br>
"work". So as a practical matter, I think we will support them. <br>
Whether the LLVM community in general feels that that's required, is<span class="apple-converted-space"> </span><br>
another question. Until for your recent comments here, and Nicolai's<span class="apple-converted-space"> </span><br>
comments above, I would have thought the answer was clearly yes. But maybe that's not the case.</span></p>
</blockquote>
<p class="MsoNormal"><span style="font-size: 9pt; font-family: "Helvetica",sans-serif;"><br>
I think this is a very good point. You (Sony) are not the only ones<span class="apple-converted-space"> </span><br>
who are concerned with GCC-command line compatibility. It definitely<span class="apple-converted-space"> </span><br>
should hold some weight. Given that this is something we could do<span class="apple-converted-space"> </span><br>
with just a little more effort, I’m not sure mere simplicity is enough<span class="apple-converted-space"> </span><br>
reason not to do it.</span></p>
</blockquote>
<p class="MsoNormal" style="margin-bottom: 12pt;"><span style="font-size: 9pt; font-family: "Helvetica",sans-serif;"><br>
Right. I'm not fundamentally opposed to having these flags, as long as we can agree that the *only* reason for having them is slightly better GCC compatibility. The "slightly better" is important, too, because promising real compatibility with any kind of fast
math-type setting would simply be a lie.<br>
<br>
So (to answer Mehdi's question in a different part of the thread), I'd consider keeping arcp around a wart, but an acceptable one. I'm fine<br>
with: IR 'fast' becomes IR 'reassociation' (or similar; algebraically correct transforms that may change rounding), and reciprocal math becomes "this thing that should logically be enabled by 'reassociation', but instead requires 'arcp' for GCC-'compatibility'
reasons".<br>
<br>
And to be clear, 'reassociation' should _not_ by itself allow transforms like X * (Y + 1) --> X * Y + X which can change the NaN-ness of the result when Infs are among the arguments. That's what 'reassociation' + 'ninf' is for.<br>
<br>
<br>
</span></p>
<blockquote style="margin-top: 5pt; margin-bottom: 5pt;">
<p class="MsoNormal" style="margin-bottom: 12pt;"><span style="font-size: 9pt; font-family: "Helvetica",sans-serif;">Also, on a slight tangent...<br>
<br>
<br>
<br>
</span></p>
<blockquote style="margin-top: 5pt; margin-bottom: 5pt;">
<blockquote style="margin-top: 5pt; margin-bottom: 5pt;">
<p class="MsoNormal"><span style="font-size: 9pt; font-family: "Helvetica",sans-serif;">I'd be really curious to know if there is anybody who really needs<span class="apple-converted-space"> </span><br>
arcp without fp-contract=fast or vice versa, or who needs both of<span class="apple-converted-space"> </span><br>
these but not the X*log2(0.5*Y) transform you mentioned, and so<span class="apple-converted-space"> </span><br>
on.[1]</span></p>
</blockquote>
</blockquote>
<p class="MsoNormal"><span style="font-size: 9pt; font-family: "Helvetica",sans-serif;"><br>
I just wanted to mention that fp-contract relates to things like FMA<span class="apple-converted-space"> </span><br>
and shouldn’t be confused with fast-math.</span></p>
</blockquote>
<p class="MsoNormal" style="margin-bottom: 12pt;"><span style="font-size: 9pt; font-family: "Helvetica",sans-serif;"><br>
It's conceptually the same type of thing though, isn't it? At least fp-contract=fast, which means "use FMA even when it changes floating point results (due to different rounding)". This is kind of like the 'fast' flag, which means "do all sorts of transformations
even when they change floating point results (due to different rounding)". I don't know whether clang -ffast-math enables fp-contract=fast, but I'd say that in a clean, from-scratch design, fp-contract=fast shouldn't be a separate flag.<br>
<br>
Cheers,<br>
Nicolai<br>
<br>
<br>
</span></p>
<blockquote style="margin-top: 5pt; margin-bottom: 5pt;">
<p class="MsoNormal" style="margin-bottom: 12pt;"><span style="font-size: 9pt; font-family: "Helvetica",sans-serif;"><br>
<br>
<br>
-Andy<br>
<br>
<br>
<br>
<br>
<br>
*From:*Ristow, Warren [<a href="mailto:warren.ristow@sony.com" target="_blank">mailto:warren.ristow@sony.com</a>]<br>
*Sent:* Thursday, November 17, 2016 12:51 AM<br>
*To:* <a href="mailto:mehdi.amini@apple.com" target="_blank">mehdi.amini@apple.com</a><br>
*Cc:* Kaylor, Andrew <<a href="mailto:andrew.kaylor@intel.com" target="_blank">andrew.kaylor@intel.com</a>>;<span class="apple-converted-space"> </span><br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>; Nicolai Hähnle <<a href="mailto:nhaehnle@gmail.com" target="_blank">nhaehnle@gmail.com</a>><br>
*Subject:* RE: [llvm-dev] RFC: Consider changing the semantics of 'fast'<br>
flag implying all fast-math-flags<br>
<br>
<br>
<br>
Those are all good points. Your reassociation point in the context of<span class="apple-converted-space"> </span><br>
inlining is particularly interesting.<br>
<br>
<br>
<br>
FWIW, we also have a case where a customer wants '-fno-associative-math'<br>
to suppress reassociation under '-ffastmath'. It would take me a<span class="apple-converted-space"> </span><br>
while to find the specifics of the issue, but it was (if my memory is<span class="apple-converted-space"> </span><br>
right) more of a real use-case. (That is to say, the code that was "failing"<br>
due to reassociation didn't have an obvious fix like the reciprocal<span class="apple-converted-space"> </span><br>
situation, here, other than to turn off fast-math.) In fact, the<span class="apple-converted-space"> </span><br>
request to suppress reassociation was the motivation for creating<br>
PR27372 in the first place (which eventually fed into this thread). I<span class="apple-converted-space"> </span><br>
have to say that on the reassociation point, my concern is that to<span class="apple-converted-space"> </span><br>
really suppress that, we will have to suppress so much, that there<span class="apple-converted-space"> </span><br>
will hardly be any point in using -ffast-math.<br>
<br>
<br>
<br>
I'd say your comments here are very similar to what Nicolai said in<span class="apple-converted-space"> </span><br>
another subthread of this discussion:<br>
<br>
<br>
<br>
</span></p>
<blockquote style="margin-top: 5pt; margin-bottom: 5pt;">
<blockquote style="margin-top: 5pt; margin-bottom: 5pt;">
<p class="MsoNormal"><span style="font-size: 9pt; font-family: "Helvetica",sans-serif;">I'd be really curious to know if there is anybody who really needs<span class="apple-converted-space"> </span><br>
arcp</span></p>
</blockquote>
</blockquote>
<p class="MsoNormal" style="margin-bottom: 12pt;"><span style="font-size: 9pt; font-family: "Helvetica",sans-serif;"> </span></p>
<blockquote style="margin-top: 5pt; margin-bottom: 5pt;">
<blockquote style="margin-top: 5pt; margin-bottom: 5pt;">
<p class="MsoNormal"><span style="font-size: 9pt; font-family: "Helvetica",sans-serif;">without fp-contract=fast or vice versa, or who needs both of these<span class="apple-converted-space"> </span><br>
but</span></p>
</blockquote>
</blockquote>
<p class="MsoNormal" style="margin-bottom: 12pt;"><span style="font-size: 9pt; font-family: "Helvetica",sans-serif;"> </span></p>
<blockquote style="margin-top: 5pt; margin-bottom: 5pt;">
<blockquote style="margin-top: 5pt; margin-bottom: 5pt;">
<p class="MsoNormal"><span style="font-size: 9pt; font-family: "Helvetica",sans-serif;">not the X*log2(0.5*Y) transform you mentioned, and so on.[1]</span></p>
</blockquote>
</blockquote>
<p class="MsoNormal" style="margin-bottom: 12pt;"><span style="font-size: 9pt; font-family: "Helvetica",sans-serif;"> </span></p>
<blockquote style="margin-top: 5pt; margin-bottom: 5pt;">
<blockquote style="margin-top: 5pt; margin-bottom: 5pt;">
<p class="MsoNormal"><span style="font-size: 9pt; font-family: "Helvetica",sans-serif;">...</span></p>
</blockquote>
</blockquote>
<p class="MsoNormal" style="margin-bottom: 12pt;"><span style="font-size: 9pt; font-family: "Helvetica",sans-serif;"> </span></p>
<blockquote style="margin-top: 5pt; margin-bottom: 5pt;">
<blockquote style="margin-top: 5pt; margin-bottom: 5pt;">
<p class="MsoNormal"><span style="font-size: 9pt; font-family: "Helvetica",sans-serif;">[1] One case I _can_ think of (and which may have been a reason for<span class="apple-converted-space"> </span><br>
the</span></p>
</blockquote>
</blockquote>
<p class="MsoNormal" style="margin-bottom: 12pt;"><span style="font-size: 9pt; font-family: "Helvetica",sans-serif;"> </span></p>
<blockquote style="margin-top: 5pt; margin-bottom: 5pt;">
<blockquote style="margin-top: 5pt; margin-bottom: 5pt;">
<p class="MsoNormal"><span style="font-size: 9pt; font-family: "Helvetica",sans-serif;">proliferation of flags in the first place) is somebody who enables<span class="apple-converted-space"> </span><br>
fast</span></p>
</blockquote>
</blockquote>
<p class="MsoNormal" style="margin-bottom: 12pt;"><span style="font-size: 9pt; font-family: "Helvetica",sans-serif;"> </span></p>
<blockquote style="margin-top: 5pt; margin-bottom: 5pt;">
<blockquote style="margin-top: 5pt; margin-bottom: 5pt;">
<p class="MsoNormal"><span style="font-size: 9pt; font-family: "Helvetica",sans-serif;">math, but then doesn't want their results to change when they update<span class="apple-converted-space"> </span><br>
the</span></p>
</blockquote>
</blockquote>
<p class="MsoNormal" style="margin-bottom: 12pt;"><span style="font-size: 9pt; font-family: "Helvetica",sans-serif;"> </span></p>
<blockquote style="margin-top: 5pt; margin-bottom: 5pt;">
<blockquote style="margin-top: 5pt; margin-bottom: 5pt;">
<p class="MsoNormal"><span style="font-size: 9pt; font-family: "Helvetica",sans-serif;">compiler and get a new set of optimizations. But IMO that's a use<span class="apple-converted-space"> </span><br>
case</span></p>
</blockquote>
</blockquote>
<p class="MsoNormal" style="margin-bottom: 12pt;"><span style="font-size: 9pt; font-family: "Helvetica",sans-serif;"> </span></p>
<blockquote style="margin-top: 5pt; margin-bottom: 5pt;">
<blockquote style="margin-top: 5pt; margin-bottom: 5pt;">
<p class="MsoNormal"><span style="font-size: 9pt; font-family: "Helvetica",sans-serif;">that should be explicitly rejected.</span></p>
</blockquote>
</blockquote>
<p class="MsoNormal" style="margin-bottom: 12pt;"><span style="font-size: 9pt; font-family: "Helvetica",sans-serif;"><br>
<br>
<br>
I think those are all really good points, and an argument can be made<span class="apple-converted-space"> </span><br>
that when -ffast-math gives you results you don't want, then you just<span class="apple-converted-space"> </span><br>
have to turn it off. Essentially, the user can't "have his cake and<span class="apple-converted-space"> </span><br>
eat it too".<br>
<br>
<br>
<br>
All that said, I think we (the company I work for, Sony) will have to<span class="apple-converted-space"> </span><br>
implement support for these switches. It comes down to GCC has these<span class="apple-converted-space"> </span><br>
switches (e.g., -fno-reciprocal-math and -fno-associative-math), and<span class="apple-converted-space"> </span><br>
they do suppress the transformations for our customers. They switch<span class="apple-converted-space"> </span><br>
to Clang/LLVM, they use the same switches, and it doesn't "work". So<span class="apple-converted-space"> </span><br>
as a practical matter, I think we will support them. Whether the LLVM<span class="apple-converted-space"> </span><br>
community in general feels that that's required, is another question.<br>
Until for your recent comments here, and Nicolai's comments above, I<span class="apple-converted-space"> </span><br>
would have thought the answer was clearly yes. But maybe that's not<span class="apple-converted-space"> </span><br>
the case.<br>
<br>
<br>
<br>
In summary, irrespective of any (subjective?) assessment of how<span class="apple-converted-space"> </span><br>
legitimate a particular use-case is, do we want switches like:<br>
<br>
<br>
<br>
-ffast-math -fno-reciprocal-math<br>
<br>
-ffast-math -fno-associative-math<br>
<br>
<br>
<br>
to work?<br>
<br>
<br>
<br>
For me, the answer is yes, because I have multiple customers that tell<span class="apple-converted-space"> </span><br>
me they really want to leave -ffast-math on, but they want to be able<span class="apple-converted-space"> </span><br>
to disable these sub-categories. I've been approaching this under the<span class="apple-converted-space"> </span><br>
assumption that the answer is yes for the Clang/LLVM community in general.<br>
<br>
<br>
<br>
Thanks,<br>
<br>
-Warren<br>
<br>
<br>
<br>
*From:*<a href="mailto:mehdi.amini@apple.com" target="_blank">mehdi.amini@apple.com</a> <<a href="mailto:mehdi.amini@apple.com" target="_blank">mailto:mehdi.amini@apple.com</a>><span class="apple-converted-space"> </span><br>
[<a href="mailto:mehdi.amini@apple.com" target="_blank">mailto:mehdi.amini@apple.com</a>]<br>
*Sent:* Wednesday, November 16, 2016 10:46 PM<br>
*To:* Ristow, Warren <<a href="mailto:warren.ristow@sony.com" target="_blank">warren.ristow@sony.com</a><span class="apple-converted-space"> </span><br>
<<a href="mailto:warren.ristow@sony.com" target="_blank">mailto:warren.ristow@sony.com</a>>><br>
*Cc:* Kaylor, Andrew <<a href="mailto:andrew.kaylor@intel.com" target="_blank">andrew.kaylor@intel.com</a><span class="apple-converted-space"> </span><br>
<<a href="mailto:andrew.kaylor@intel.com" target="_blank">mailto:andrew.kaylor@intel.com</a>>>; <a href="mailto:llvm-dev@lists.llvm.org" target="_blank">
llvm-dev@lists.llvm.org</a><span class="apple-converted-space"> </span><br>
<<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">mailto:llvm-dev@lists.llvm.org</a>>; Nicolai Hähnle <<a href="mailto:nhaehnle@gmail.com" target="_blank">nhaehnle@gmail.com</a><span class="apple-converted-space"> </span><br>
<<a href="mailto:nhaehnle@gmail.com" target="_blank">mailto:nhaehnle@gmail.com</a>>><br>
*Subject:* Re: [llvm-dev] RFC: Consider changing the semantics of 'fast'<br>
flag implying all fast-math-flags<br>
<br>
<br>
<br>
<br>
<br>
On Nov 16, 2016, at 10:04 PM, Ristow, Warren <<a href="mailto:warren.ristow@sony.com" target="_blank">warren.ristow@sony.com</a><br>
<<a href="mailto:warren.ristow@sony.com" target="_blank">mailto:warren.ristow@sony.com</a>>> wrote:<br>
<br>
<br>
<br>
</span></p>
<blockquote style="margin-top: 5pt; margin-bottom: 5pt;">
<p class="MsoNormal"><span style="font-size: 9pt; font-family: "Helvetica",sans-serif;">Can you elaborate what kind of runtime failure is the reciprocal</span></p>
</blockquote>
<p class="MsoNormal" style="margin-bottom: 12pt;"><span style="font-size: 9pt; font-family: "Helvetica",sans-serif;"> transformation triggering?<br>
<br>
<br>
<br>
Yes. It was along the lines of:<br>
<br>
<br>
<br>
{<br>
<br>
float x = a / c;<br>
<br>
float y = b / c;<br>
<br>
<br>
<br>
if (y == 1.0f) {<br>
<br>
// do some processing for when 'b' and 'c' are equal<br>
<br>
} else {<br>
<br>
// do other processing<br>
<br>
}<br>
<br>
<br>
<br>
use(x, y);<br>
<br>
}<br>
<br>
<br>
<br>
Of course they understood they could easily change this code once<br>
they understood the issue.<br>
<br>
<br>
<br>
But the fact that it "failed" for non-edge-case values of 'c', they<br>
were worried. As an example of the non-edge-case aspect, when 'c'<br>
is 41.0f (and so of course 'b' is 41.0f), intuitively they felt that<br>
this “would work precisely”, even with fast-math. Once they<br>
understood more, they agreed this was reasonable with fast-math, but<br>
they had the underlying concern that if they encountered one case<br>
where 'num' and 'den' were equal (and non-edge-case), yet 'num /<br>
den' wasn't precisely 1.0f, then even if they fixed this situation<br>
where they encountered it, it might be lurking elsewhere in their<br>
code, and so they wanted to disable that transformation.<br>
<br>
<br>
<br>
Thanks for elaborating.<br>
<br>
<br>
<br>
I’d be reluctant to call this situation a real use-case though.<br>
<br>
Is the the distinction on reciprocal really make sense here? This user<span class="apple-converted-space"> </span><br>
can have the same “surprising" anywhere in their code-base with<span class="apple-converted-space"> </span><br>
reassociation as well:<br>
<br>
<br>
<br>
void foo (float a, float b) {<br>
<br>
float x = a - b;<br>
<br>
if (x == 0)<br>
<br>
… // only if a == b<br>
<br>
}<br>
<br>
<br>
<br>
That would sound totally reasonable, unless foo is inlined and<span class="apple-converted-space"> </span><br>
reassociation would lead to a non-zero value for x even when a and b<span class="apple-converted-space"> </span><br>
passed in to foo "if it wasn’t inlined" would be identical!<br>
<br>
<br>
<br>
(Reminds me somehow of a client that was bitten by nnan: their<span class="apple-converted-space"> </span><br>
assumption was that as long as they didn’t introduce NaN in the<span class="apple-converted-space"> </span><br>
program everything was fine. However with fast-math some<span class="apple-converted-space"> </span><br>
transformations were introducing NaN where there wasn’t before and<span class="apple-converted-space"> </span><br>
propagating to other computation that were transformed under the<span class="apple-converted-space"> </span><br>
assumption that no NaN would show up, it also turns out that making<span class="apple-converted-space"> </span><br>
the code safe against NaN and efficient at the same time is hard,<span class="apple-converted-space"> </span><br>
especially when the code itself it compiled with fast-math).<br>
<br>
<br>
<br>
—<br>
<br>
Mehdi<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
*From:* <a href="mailto:mehdi.amini@apple.com" target="_blank">mehdi.amini@apple.com</a> <<a href="mailto:mehdi.amini@apple.com" target="_blank">mailto:mehdi.amini@apple.com</a>><br>
[<a href="mailto:mehdi.amini@apple.com" target="_blank">mailto:mehdi.amini@apple.com</a>]<br>
*Sent:* Wednesday, November 16, 2016 7:11 PM<br>
*To:* Ristow, Warren <<a href="mailto:warren.ristow@sony.com" target="_blank">warren.ristow@sony.com</a><br>
<<a href="mailto:warren.ristow@sony.com" target="_blank">mailto:warren.ristow@sony.com</a>>><br>
*Cc:* Kaylor, Andrew <<a href="mailto:andrew.kaylor@intel.com" target="_blank">andrew.kaylor@intel.com</a><br>
<<a href="mailto:andrew.kaylor@intel.com" target="_blank">mailto:andrew.kaylor@intel.com</a>>>;
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">mailto:llvm-dev@lists.llvm.org</a>>; Nicolai Hähnle <<a href="mailto:nhaehnle@gmail.com" target="_blank">nhaehnle@gmail.com</a><br>
<<a href="mailto:nhaehnle@gmail.com" target="_blank">mailto:nhaehnle@gmail.com</a>>><br>
*Subject:* Re: [llvm-dev] RFC: Consider changing the semantics of<br>
'fast' flag implying all fast-math-flags<br>
<br>
<br>
<br>
<br>
<br>
On Nov 16, 2016, at 6:22 PM, Ristow, Warren<br>
<<a href="mailto:warren.ristow@sony.com" target="_blank">warren.ristow@sony.com</a> <<a href="mailto:warren.ristow@sony.com" target="_blank">mailto:warren.ristow@sony.com</a>>> wrote:<br>
<br>
<br>
<br>
</span></p>
<blockquote style="margin-top: 5pt; margin-bottom: 5pt;">
<p class="MsoNormal"><span style="font-size: 9pt; font-family: "Helvetica",sans-serif;">... except that Warren’s proposal that started this<span class="apple-converted-space"> </span></span></p>
</blockquote>
<p class="MsoNormal" style="margin-bottom: 12pt;"><span style="font-size: 9pt; font-family: "Helvetica",sans-serif;">discussion seems to imply that he<br>
<br>
</span></p>
<blockquote style="margin-top: 5pt; margin-bottom: 5pt;">
<p class="MsoNormal"><span style="font-size: 9pt; font-family: "Helvetica",sans-serif;">has a use case that requires reciprocals to be turned off separately.</span></p>
</blockquote>
<p class="MsoNormal" style="margin-bottom: 12pt;"><span style="font-size: 9pt; font-family: "Helvetica",sans-serif;"><br>
<br>
<br>
Just to close this loose end, yes I have a use case.<br>
<br>
<br>
<br>
Specifically, we have a customer that turns on '‑ffast‑math',<br>
but was getting a runtime failure due to the<br>
reciprocal-transformation being done.<br>
<br>
<br>
<br>
Can you elaborate what kind of runtime failure is the reciprocal<br>
transformation triggering?<br>
<br>
<br>
<br>
—<br>
<br>
Mehdi<br>
<br>
<br>
<br>
<br>
<br>
They don't want turn off fast‑math because they like the<br>
performance improvement, and can live with the imprecision in<br>
most cases. So they wanted to suppress just the<br>
reciprocal-transformation. I intended to tell them the solution<br>
was simple: use '‑ffast‑math ‑fno‑reciprocal‑math'. But on<br>
trying it myself, I ran into the issue here.<br>
<br>
<br>
<br>
Thanks,<br>
<br>
-Warren<br>
<br>
<br>
<br>
*From:* Kaylor, Andrew [<a href="mailto:andrew.kaylor@intel.com" target="_blank">mailto:andrew.kaylor@intel.com</a>]<br>
*Sent:* Wednesday, November 16, 2016 4:13 PM<br>
*To:* Mehdi Amini <<a href="mailto:mehdi.amini@apple.com" target="_blank">mehdi.amini@apple.com</a><br>
<<a href="mailto:mehdi.amini@apple.com" target="_blank">mailto:mehdi.amini@apple.com</a>>>; Ristow, Warren<br>
<<a href="mailto:warren.ristow@sony.com" target="_blank">warren.ristow@sony.com</a><br>
<<a href="mailto:warren.ristow@sony.com" target="_blank">mailto:warren.ristow@sony.com</a>>>;
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">mailto:llvm-dev@lists.llvm.org</a>>; Nicolai Hähnle<br>
<<a href="mailto:nhaehnle@gmail.com" target="_blank">nhaehnle@gmail.com</a> <<a href="mailto:nhaehnle@gmail.com" target="_blank">mailto:nhaehnle@gmail.com</a>>><br>
*Subject:* RE: [llvm-dev] RFC: Consider changing the semantics<br>
of 'fast' flag implying all fast-math-flags<br>
<br>
<br>
<br>
I don’t really like the idea of updating checks of<br>
UnsafeAlgebra() to depend on all of the other flags. It seems<br>
like it would be preferable to look at each optimization and<br>
figure out which flags it actually requires. I suspect that in<br>
many cases the “new” flag (i.e. allowing reassociation, etc.)<br>
will be what is actually needed anyway.<br>
<br>
<br>
<br>
I would be inclined to agree with Niolai’s suggestion of<br>
combining all the flags related to value safety, except that<br>
Warren’s proposal that started this discussion seems to imply<br>
that he has a use case that requires reciprocals to be turned<br>
off separately.<br>
<br>
<br>
<br>
-Andy<br>
<br>
<br>
<br>
*From:* llvm-dev [<a href="mailto:llvm-dev-bounces@lists.llvm.org" target="_blank">mailto:llvm-dev-bounces@lists.llvm.org</a>] *On<br>
Behalf Of *Mehdi Amini via llvm-dev<br>
*Sent:* Wednesday, November 16, 2016 8:55 AM<br>
*To:* Ristow, Warren <<a href="mailto:warren.ristow@sony.com" target="_blank">warren.ristow@sony.com</a><br>
<<a href="mailto:warren.ristow@sony.com" target="_blank">mailto:warren.ristow@sony.com</a>>><br>
*Cc:* <a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a> <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">mailto:llvm-dev@lists.llvm.org</a>><br>
*Subject:* Re: [llvm-dev] RFC: Consider changing the semantics<br>
of 'fast' flag implying all fast-math-flags<br>
<br>
<br>
<br>
<br>
<br>
On Nov 15, 2016, at 11:59 PM, Ristow, Warren<br>
<<a href="mailto:warren.ristow@sony.com" target="_blank">warren.ristow@sony.com</a> <<a href="mailto:warren.ristow@sony.com" target="_blank">mailto:warren.ristow@sony.com</a>>> wrote:<br>
<br>
<br>
<br>
Hi,<br>
<br>
<br>
<br>
Thanks for the quick feedback. I see your points, but I<br>
have a few questions/comments. I'll start at the end of the<br>
previous post:<br>
<br>
<br>
<br>
</span></p>
<blockquote style="margin-top: 5pt; margin-bottom: 5pt;">
<p class="MsoNormal"><span style="font-size: 9pt; font-family: "Helvetica",sans-serif;">...</span></p>
</blockquote>
<p class="MsoNormal" style="margin-bottom: 12pt;"><span style="font-size: 9pt; font-family: "Helvetica",sans-serif;"> </span></p>
<blockquote style="margin-top: 5pt; margin-bottom: 5pt;">
<p class="MsoNormal"><span style="font-size: 9pt; font-family: "Helvetica",sans-serif;">I think these are valuable problems to solve, but you should tackle them piece by piece:</span></p>
</blockquote>
<p class="MsoNormal" style="margin-bottom: 12pt;"><span style="font-size: 9pt; font-family: "Helvetica",sans-serif;"> </span></p>
<blockquote style="margin-top: 5pt; margin-bottom: 5pt;">
<p class="MsoNormal"><span style="font-size: 9pt; font-family: "Helvetica",sans-serif;"> </span></p>
</blockquote>
<p class="MsoNormal" style="margin-bottom: 12pt;"><span style="font-size: 9pt; font-family: "Helvetica",sans-serif;"> </span></p>
<blockquote style="margin-top: 5pt; margin-bottom: 5pt;">
<p class="MsoNormal"><span style="font-size: 9pt; font-family: "Helvetica",sans-serif;">1) the clang part of overriding the individual FMF and emitting the right IR is the first thing to fix.</span></p>
</blockquote>
<p class="MsoNormal" style="margin-bottom: 12pt;"><span style="font-size: 9pt; font-family: "Helvetica",sans-serif;"> </span></p>
<blockquote style="margin-top: 5pt; margin-bottom: 5pt;">
<p class="MsoNormal"><span style="font-size: 9pt; font-family: "Helvetica",sans-serif;">2) the backend is still using the global UnsafeFPMath and it should be killed.</span></p>
</blockquote>
<p class="MsoNormal" style="margin-bottom: 12pt;"><span style="font-size: 9pt; font-family: "Helvetica",sans-serif;"><br>
<br>
<br>
I addressed this point (2) for the reciprocal aspect in the<br>
patch, but of course that wasn't useful without doing<br>
something about (1).<br>
<br>
<br>
<br>
Regarding (1), over<br>
at <a href="https://reviews.llvm.org/D26708#596610" target="_blank">https://reviews.llvm.org/D26708#596610</a>, David made the<br>
same point that it should be done in Clang. I can<br>
understand that, but I wonder whether having the concept of<br>
the 'fast' flag in the IR that implies all the other FMF<br>
makes sense? I'm not seeing a good reason for it, but since<br>
this is very new to me, I can easily imagine I'm missing the<br>
big picture.<br>
<br>
<br>
<br>
For example, in the LLVM IR<br>
(<a href="http://llvm.org/docs/LangRef.html#fast-math-flags" target="_blank">http://llvm.org/docs/LangRef.html#fast-math-flags</a>) the<br>
fast-math flags 'nnan', 'ninf', 'nsz', 'arcp' and 'fast’ are<br>
defined. Except for 'fast', each of these has a fairly<br>
specific definition of what they mean. For example, for 'arcp':<br>
<br>
<br>
<br>
arcp => "Allow optimizations to use the reciprocal of an<br>
argument rather<br>
<br>
than perform division."<br>
<br>
<br>
<br>
'fast' is unusual, in that it describes a fairly generic set<br>
of aggressive floating-point optimizations:<br>
<br>
<br>
<br>
fast => "Allow algebraically equivalent transformations<br>
that may dramatically<br>
<br>
change results in floating point (e.g.<br>
reassociate). This flag implies<br>
<br>
all the others."<br>
<br>
<br>
<br>
Very loosely, 'fast' means "all the aggressive<br>
FP-transformations that are not controlled by one of the<br>
other 4, plus it implies all the other 4". If for<br>
terminology, we call those additional aggressive<br>
optimizations 'aggr', then we have:<br>
<br>
<br>
<br>
'fast' == 'aggr' + 'nnan' + 'ninf' + 'nsz' + 'arcp'<br>
<br>
<br>
<br>
So as I see it, if we want to disable only one of the other<br>
ones (like 'arcp', in my case), there isn't any way to<br>
express that with these IR flags defined this way. In<br>
short, we cannot turn on all the flags besides 'arcp'. To<br>
do that, what we want is that somehow for the Clang switches:<br>
<br>
<br>
<br>
'-ffast-math -fno-reciprocal-math'<br>
<br>
<br>
<br>
to ultimately result in LLVM IR that has the following flags<br>
on in appropriate FP ops:<br>
<br>
<br>
<br>
'aggr' + 'nnan' + 'ninf' + ‘nsz'<br>
<br>
<br>
<br>
Make sense, I missed that we can’t *subtract* from fast at the<br>
IR level.<br>
<br>
<br>
<br>
I wouldn’t be opposed to have something along the line of<br>
“aggr”, but there is a tradeoff: some transformation may be<br>
harder to guard with this model.<br>
<br>
<br>
<br>
Maybe that could be a starting point: changing the<br>
“UnsafeAlgebra” bit in the FMF to be “aggr” you mention and<br>
replace all the query to FastMathFlags::UnsafeAlgebra() to<br>
return true if all the bits are set in the Flags. This alone<br>
should be nothing more than a mechanical change I believe.<br>
<br>
The important part is then auditing all the users of<br>
UnsafeAlgebra() in the middle end and check if they can be<br>
“downgraded” to aggr safely: i.e. if they don’t need aggr *and*<br>
another flag.<br>
<br>
<br>
<br>
—<br>
<br>
Mehdi<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
But I don't see a way to express 'aggr' in the IR. We could<br>
do this, if we change the definition of the IR 'fast' flag<br>
to remove that sentence about implying all the others:<br>
<br>
<br>
<br>
fast => "Allow algebraically equivalent transformations<br>
that may dramatically<br>
<br>
change results in floating point (e.g. reassociate).<br>
<br>
<br>
<br>
(If we do something like that, we may want to change the<br>
name from 'fast' to something else (like 'aggr'), to avoid<br>
tying it too closely to the concept of the '-ffast-math'<br>
switch.)<br>
<br>
<br>
<br>
As an aside, I don't know if the "reassociate" example is<br>
the only other transformation that's allowed by 'fast' (I<br>
presume it isn't), but I think reassociation would be better<br>
expressed by a separate flag, which could then be controlled<br>
independently via '-f[no]-associative-math' switch. Not<br>
having that flag exist separately in the FMF is the origin<br>
of PR27372. But creating that flag and using it in the<br>
appropriate places would still run into these problems of<br>
'fast' implying all the others, which would make it<br>
impossible to disable reassociation while leaving all the<br>
other FMF transformations enabled.<br>
<br>
<br>
<br>
To ask a concrete question using the current definition of<br>
'fast' (which includes enabling reassociation, as the LLVM<br>
IR documentation of FMF says), how can we express in the IR<br>
that reciprocal-transformations are not allowed, but<br>
reassociation is allowed?<br>
<br>
<br>
<br>
So the bottom line is that I do see there are issues in<br>
Clang that are relevant. But as long as 'fast' means<br>
"'aggr' plus all the other FMF transformations", I don't see<br>
how we can effectively disable a subset of those other FMF<br>
transformations (while leaving 'aggr' transformations, such<br>
as reassociation, enabled). With that in mind, my patch<br>
took one step in having 'fast' no longer imply all the others.<br>
<br>
<br>
<br>
Thanks,<br>
<br>
-Warren<br>
<br>
</span></p>
</blockquote>
</blockquote>
<p class="MsoNormal"><span style="font-size: 9pt; font-family: "Helvetica",sans-serif;"><br>
_______________________________________________<br>
LLVM Developers mailing list<br>
</span><a href="mailto:llvm-dev@lists.llvm.org" target="_blank"><span style="font-size: 9pt; font-family: "Helvetica",sans-serif;">llvm-dev@lists.llvm.org</span></a><span style="font-size: 9pt; font-family: "Helvetica",sans-serif;"><br>
</span><a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" target="_blank"><span style="font-size: 9pt; font-family: "Helvetica",sans-serif;">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</span></a></p>
</div>
</blockquote>
</div>
<p class="MsoNormal"> </p>
</div>
<br>_______________________________________________<br>LLVM Developers mailing list<br>llvm-dev@lists.llvm.org<br>http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev<br></blockquote><br><br><br>-- <br><div><span name="x"></span>Hal Finkel<br>Lead, Compiler Technology and Programming Languages<br>Leadership Computing Facility<br>Argonne National Laboratory<span name="x"></span><br></div></div></body></html>