<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 15 (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;}
/* Style Definitions */
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.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.gmail-transaction-comment
{mso-style-name:gmail-transaction-comment;}
span.EmailStyle18
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri",sans-serif;}
@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 lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal">> Is this a bug? We transformed the original expression into:<br>
> x * y + x<br>
<br>
<span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">I’d say yes, it’s a bug.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">Unless ‑ffast‑math is used (or some appropriate subset that gives us leeway, like ‑fno‑honor‑infinities or ‑fno‑honor‑nans, or somesuch), the re-association isn’t
allowed, and that blocks the madd contraction.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">-Warren<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">From:</span></b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"> Sanjay Patel [mailto:spatel@rotateright.com]
<br>
<b>Sent:</b> Thursday, November 17, 2016 3:22 PM<br>
<b>To:</b> cfe-dev <cfe-dev@lists.llvm.org>; llvm-dev <llvm-dev@lists.llvm.org><br>
<b>Cc:</b> Nicolai Hähnle <nhaehnle@gmail.com>; Hal Finkel <hfinkel@anl.gov>; Mehdi Amini <mehdi.amini@apple.com>; Ristow, Warren <warren.ristow@sony.com>; andrew.kaylor@intel.com<br>
<b>Subject:</b> what does -ffp-contract=fast allow?<o:p></o:p></span></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt">This is just paraphrasing from D26602, so credit to Nicolai for first raising the issue there.<br>
<br>
float foo(float x, float y) {<br>
return x * (y + 1);<br>
}<br>
<br>
$ ./clang -O2 xy1.c -S -o - -target aarch64 -ffp-contract=fast | grep fm<br>
fmadd s0, s1, s0, s0<br>
<br>
Is this a bug? We transformed the original expression into:<br>
x * y + x<br>
<br>
When x=INF and y=0, the code returns INF if we don't reassociate. With reassociation to FMA, it returns NAN because 0 * INF = NAN.<br>
<br>
1. I used aarch64 as the example target, but this is not target-dependent (as long as the target has FMA).<br>
<br>
2. This is *not* -ffast-math...or is it? The C standard only shows on/off settings for the associated FP_CONTRACT pragma.<br>
<br>
3. AFAIK, clang has no documentation for -ffp-contract:<br>
<a href="http://clang.llvm.org/docs/UsersManual.html">http://clang.llvm.org/docs/UsersManual.html</a><br>
<br>
4. GCC says:<br>
<a href="https://gcc.gnu.org/onlinedocs/gcc-6.2.0/gcc/Optimize-Options.html#Optimize-Options">https://gcc.gnu.org/onlinedocs/gcc-6.2.0/gcc/Optimize-Options.html#Optimize-Options</a><br>
"-ffp-contract=fast enables floating-point expression contraction such as forming of fused multiply-add operations if the target has native support for them."<br>
<br>
5. The LLVM backend (where this reassociation currently happens) shows:<br>
FPOpFusion::Fast - Enable fusion of FP ops wherever it's profitable.<o:p></o:p></p>
</div>
</div>
</body>
</html>