<div dir="ltr"><div><div><div><div>fp-contract is confusing, so let me try to summarize that and the underlying implementation:<br></div><br>1. -ffp-contract=on means honor the compiler's default FP_CONTRACT setting or any FP_CONTRACT pragmas in the source. Currently, clang defaults to "OFF". The shouting is not an accident; this is not the same as the flag's "off" setting. This is described nicely here:<br><a href="https://reviews.llvm.org/D24481">https://reviews.llvm.org/D24481</a><br><br></div><div>If we set "on" in the invocation *and* we set "ON" in the source, clang will generate @llvm.fmuladd intrinsics for expressions like x*y+z. If you split that into 2 lines in C with a temp variable assignment, it's no longer a single expression, so no FMA for you. The @llvm.fmuladd intrinsic is our way of preserving the C source information through the optimizer. If we don't end up producing an FMA instruction for the target in this case, it's a bug. <br></div><div><br></div>2. -ffp-contract=fast means override the compiler's default "OFF" setting and override source pragmas to generate FMA when possible, even across C expressions. The "fast" naming is unfortunate because this does *not* enable most fast-math. Ie, as everyone in this thread agrees so far, we are not allowed to do the reassociation in the example. It's not strict math though because of that trailing clause that let's us generate FMA across expressions.<br><br>Here's where it gets more complicated and possibly buggy. Clang does not generate llvm.fmuladd intrinsics with this setting. In this mode, clang generates individual fmul and fadd instructions and relies on the backend to fuse those back together. More background here: <br><a href="https://llvm.org/bugs/show_bug.cgi?id=17211">https://llvm.org/bugs/show_bug.cgi?id=17211</a><br></div><br>I don't know if it's possible, but if we're in this mode and some IR transform pass managed to
move/kill an fmul or fadd that was destined to be part of an FMA, I
think that would be a bug. This mode is also completely broken with LTO because we're using a TargetOption to communicate the FMA mode to the backend; there is no instruction-level or function-level attribute/metadata for FMA-ness:<br></div><a href="https://llvm.org/bugs/show_bug.cgi?id=25721">https://llvm.org/bugs/show_bug.cgi?id=25721</a><br><div><br></div><div>To tie this back to the earlier thread about changes to IR FMF, the possibility of adding FMA bits to FMF (as well as storing all FMF in metadata) was discussed here:<br><a href="https://llvm.org/bugs/show_bug.cgi?id=13118">https://llvm.org/bugs/show_bug.cgi?id=13118</a><br></div><div><br></div><div>3. The backend needs a thread of its own. We have at least these mechanisms to handle FMA codegen:<br></div><div>a. TargetOptions for LessPreciseFPMADOption, UnsafeFPMath, NoInfsFPMath, NoNaNsFPMath, AllowFPOpFusion (Fast, Standard, Strict)<br></div><div>b. SDNodeFlags for UnsafeAlgebra, NoNaNs, NoInfs, NoSignedZeros (but nothing for FMA since IR FMF has nothing for FMA)<br></div><div>c. SelectionDAGTargetInfo::generateFMAsInMachineCombiner()<br></div><div>d. TargetLoweringBase::isFMAFasterThanFMulAndFAdd()<br></div><div>e. TargetLoweringBase::enableAggressiveFMAFusion()<br></div><div>f. ISD::FMA (no intermediate rounding step) and ISD::FMAD (has intermediate rounding) nodes<br><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Nov 17, 2016 at 6:03 PM, Finkel, Hal J. <span dir="ltr"><<a href="mailto:hfinkel@anl.gov" target="_blank">hfinkel@anl.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>
<div>
<div></div>
<div><font style="color:#333333"><i>Sent from my Verizon Wireless 4G LTE DROID</i></font></div><span class="">
<div><font style="color:#333333"><i>On Nov 17, 2016 5:53 PM, Mehdi Amini <</i></font><a href="mailto:mehdi.amini@apple.com" target="_blank"><font style="color:#333333"><i>mehdi.amini@apple.com</i></font></a><font style="color:#333333"><i>> wrote:</i></font></div>
<div><font style="color:#333333"><i>></i></font></div>
<div><font style="color:#333333"><i>></i></font></div>
<div><font style="color:#333333"><i>>> On Nov 17, 2016, at 4:33 PM, Hal Finkel <</i></font><a href="mailto:hfinkel@anl.gov" target="_blank"><font style="color:#333333"><i>hfinkel@anl.gov</i></font></a><font style="color:#333333"><i>> wrote:</i></font></div>
<div><font style="color:#333333"><i>>></i></font></div>
<div><font style="color:#333333"><i>>></i></font></div>
<div><font style="color:#333333"><i>>> ______________________________<wbr>__</i></font></div>
<div><font style="color:#333333"><i>>>></i></font></div>
<div><font style="color:#333333"><i>>>> From: "Warren Ristow" <</i></font><a href="mailto:warren.ristow@sony.com" target="_blank"><font style="color:#333333"><i>warren.ristow@sony.com</i></font></a><font style="color:#333333"><i>></i></font></div>
<div><font style="color:#333333"><i>>>> To: "Sanjay Patel" <</i></font><a href="mailto:spatel@rotateright.com" target="_blank"><font style="color:#333333"><i>spatel@rotateright.com</i></font></a><font style="color:#333333"><i>>, "cfe-dev" <</i></font><a href="mailto:cfe-dev@lists.llvm.org" target="_blank"><font style="color:#333333"><i>cfe-dev@lists.llvm.org</i></font></a><font style="color:#333333"><i>>,
"llvm-dev" <</i></font><a href="mailto:llvm-dev@lists.llvm.org" target="_blank"><font style="color:#333333"><i>llvm-dev@lists.llvm.org</i></font></a><font style="color:#333333"><i>></i></font></div>
<div><font style="color:#333333"><i>>>> Cc: "Nicolai Hähnle" <</i></font><a href="mailto:nhaehnle@gmail.com" target="_blank"><font style="color:#333333"><i>nhaehnle@gmail.com</i></font></a><font style="color:#333333"><i>>, "Hal Finkel" <</i></font><a href="mailto:hfinkel@anl.gov" target="_blank"><font style="color:#333333"><i>hfinkel@anl.gov</i></font></a><font style="color:#333333"><i>>,
"Mehdi Amini" <</i></font><a href="mailto:mehdi.amini@apple.com" target="_blank"><font style="color:#333333"><i>mehdi.amini@apple.com</i></font></a><font style="color:#333333"><i>>, "andrew kaylor" <</i></font><a href="mailto:andrew.kaylor@intel.com" target="_blank"><font style="color:#333333"><i>andrew.kaylor@intel.com</i></font></a><font style="color:#333333"><i>></i></font></div>
<div><font style="color:#333333"><i>>>> Sent: Thursday, November 17, 2016 5:58:58 PM</i></font></div>
<div><font style="color:#333333"><i>>>> Subject: RE: what does -ffp-contract=fast allow?</i></font></div>
<div><font style="color:#333333"><i>>>></i></font></div>
<div><font style="color:#333333"><i>>>> > Is this a bug? We transformed the original expression into:</i></font></div>
<div><font style="color:#333333"><i>>>> > x * y + x</i></font></div>
<div><font style="color:#333333"><i>>>></i></font></div>
<div><font style="color:#333333"><i>>>> I’d say yes, it’s a bug.</i></font></div>
<div><font style="color:#333333"><i>>>></i></font></div>
<div><font style="color:#333333"><i>>>> </i></font></div>
<div><font style="color:#333333"><i>>>></i></font></div>
<div><font style="color:#333333"><i>>>> 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.</i></font></div>
<div><font style="color:#333333"><i>>></i></font></div>
<div><font style="color:#333333"><i>>> I agree. FP contraction alone only allows us to do x*y+z -> fma(x,y,z).</i></font></div>
<div><font style="color:#333333"><i>></i></font></div>
<div><font style="color:#333333"><i>></i></font></div>
<div><font style="color:#333333"><i>> I agree too, but the more difficult question is "which flags are needed here?”</i></font></div>
<div><font style="color:#333333"><i>> Would FPContract + no-inf be enough? If not why and how to document it?</i></font></div>
<div><font style="color:#333333"><i><br>
</i></font></div>
</span><div><font style="color:#333333"><i>I think that the relevant question is: Is the contracted form more precise for all inputs (or the same precision as the original)? If so, then this should be allowed with just fp-contract+no-inf. Otherwise, more is required.</i></font></div><span class="HOEnZb"><font color="#888888">
<div><font style="color:#333333"><i><br>
</i></font></div>
<div><font style="color:#333333"><i>-Hal</i></font></div></font></span><div><div class="h5">
<div><font style="color:#333333"><i><br>
</i></font></div>
<div><font style="color:#333333"><i>></i></font></div>
<div><font style="color:#333333"><i>></i></font></div>
<div><font style="color:#333333"><i>> — </i></font></div>
<div><font style="color:#333333"><i>> Mehdi</i></font></div>
<div><font style="color:#333333"><i>></i></font></div>
<div><font style="color:#333333"><i>></i></font></div>
<div><font style="color:#333333"><i>></i></font></div>
<div><font style="color:#333333"><i>>>> </i></font></div>
<div><font style="color:#333333"><i>>>></i></font></div>
<div><font style="color:#333333"><i>>>> From: Sanjay Patel [mailto:</i></font><a href="mailto:spatel@rotateright.com" target="_blank"><font style="color:#333333"><i>spatel@rotateright.com</i></font></a><font style="color:#333333"><i><wbr>] </i></font></div>
<div><font style="color:#333333"><i>>>> Sent: Thursday, November 17, 2016 3:22 PM</i></font></div>
<div><font style="color:#333333"><i>>>> To: cfe-dev <</i></font><a href="mailto:cfe-dev@lists.llvm.org" target="_blank"><font style="color:#333333"><i>cfe-dev@lists.llvm.org</i></font></a><font style="color:#333333"><i>>; llvm-dev <</i></font><a href="mailto:llvm-dev@lists.llvm.org" target="_blank"><font style="color:#333333"><i>llvm-dev@lists.llvm.org</i></font></a><font style="color:#333333"><i>></i></font></div>
<div><font style="color:#333333"><i>>>> Cc: Nicolai Hähnle <</i></font><a href="mailto:nhaehnle@gmail.com" target="_blank"><font style="color:#333333"><i>nhaehnle@gmail.com</i></font></a><font style="color:#333333"><i>>; Hal Finkel <</i></font><a href="mailto:hfinkel@anl.gov" target="_blank"><font style="color:#333333"><i>hfinkel@anl.gov</i></font></a><font style="color:#333333"><i>>;
Mehdi Amini <</i></font><a href="mailto:mehdi.amini@apple.com" target="_blank"><font style="color:#333333"><i>mehdi.amini@apple.com</i></font></a><font style="color:#333333"><i>>; Ristow, Warren <</i></font><a href="mailto:warren.ristow@sony.com" target="_blank"><font style="color:#333333"><i>warren.ristow@sony.com</i></font></a><font style="color:#333333"><i>>;
</i></font><a href="mailto:andrew.kaylor@intel.com" target="_blank"><font style="color:#333333"><i>andrew.kaylor@intel.com</i></font></a></div>
<div><font style="color:#333333"><i>>>> Subject: what does -ffp-contract=fast allow?</i></font></div>
<div><font style="color:#333333"><i>>>></i></font></div>
<div><font style="color:#333333"><i>>>> </i></font></div>
<div><font style="color:#333333"><i>>>></i></font></div>
<div><font style="color:#333333"><i>>>> This is just paraphrasing from D26602, so credit to Nicolai for first raising the issue there.</i></font></div>
<div><font style="color:#333333"><i>>>></i></font></div>
<div><font style="color:#333333"><i>>>> float foo(float x, float y) {</i></font></div>
<div><font style="color:#333333"><i>>>> return x * (y + 1);</i></font></div>
<div><font style="color:#333333"><i>>>> }</i></font></div>
<div><font style="color:#333333"><i>>>></i></font></div>
<div><font style="color:#333333"><i>>>> $ ./clang -O2 xy1.c -S -o - -target aarch64 -ffp-contract=fast | grep fm</i></font></div>
<div><font style="color:#333333"><i>>>> fmadd s0, s1, s0, s0</i></font></div>
<div><font style="color:#333333"><i>>>></i></font></div>
<div><font style="color:#333333"><i>>>> Is this a bug? We transformed the original expression into:</i></font></div>
<div><font style="color:#333333"><i>>>> x * y + x</i></font></div>
<div><font style="color:#333333"><i>>>></i></font></div>
<div><font style="color:#333333"><i>>>> 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.</i></font></div>
<div><font style="color:#333333"><i>>>></i></font></div>
<div><font style="color:#333333"><i>>>> 1. I used aarch64 as the example target, but this is not target-dependent (as long as the target has FMA).</i></font></div>
<div><font style="color:#333333"><i>>>></i></font></div>
<div><font style="color:#333333"><i>>>> 2. This is *not* -ffast-math...or is it? The C standard only shows on/off settings for the associated FP_CONTRACT pragma.</i></font></div>
<div><font style="color:#333333"><i>>>></i></font></div>
<div><font style="color:#333333"><i>>>> 3. AFAIK, clang has no documentation for -ffp-contract:</i></font></div>
<div><font style="color:#333333"><i>>>> </i></font><a href="http://clang.llvm.org/docs/UsersManual.html" target="_blank"><font style="color:#333333"><i>http://clang.llvm.org/docs/<wbr>UsersManual.html</i></font></a></div>
<div><font style="color:#333333"><i>>>></i></font></div>
<div><font style="color:#333333"><i>>>> 4. GCC says:</i></font></div>
<div><font style="color:#333333"><i>>>> </i></font><a href="https://gcc.gnu.org/onlinedocs/gcc-6.2.0/gcc/Optimize-Options.html#Optimize-Options" target="_blank"><font style="color:#333333"><i>https://gcc.gnu.org/<wbr>onlinedocs/gcc-6.2.0/gcc/<wbr>Optimize-Options.html#<wbr>Optimize-Options</i></font></a></div>
<div><font style="color:#333333"><i>>>> "-ffp-contract=fast enables floating-point expression contraction such as forming of fused multiply-add operations if the target has native support for them."</i></font></div>
<div><font style="color:#333333"><i>>>></i></font></div>
<div><font style="color:#333333"><i>>>> 5. The LLVM backend (where this reassociation currently happens) shows:</i></font></div>
<div><font style="color:#333333"><i>>>> FPOpFusion::Fast - Enable fusion of FP ops wherever it's profitable.</i></font></div>
<div><font style="color:#333333"><i>>></i></font></div>
<div><font style="color:#333333"><i>>></i></font></div>
<div><font style="color:#333333"><i>>></i></font></div>
<div><font style="color:#333333"><i>>></i></font></div>
<div><font style="color:#333333"><i>>> -- </i></font></div>
<div><font style="color:#333333"><i>>> Hal Finkel</i></font></div>
<div><font style="color:#333333"><i>>> Lead, Compiler Technology and Programming Languages</i></font></div>
<div><font style="color:#333333"><i>>> Leadership Computing Facility</i></font></div>
<div><font style="color:#333333"><i>>> Argonne National Laboratory</i></font></div>
<div><font style="color:#333333"><i>></i></font></div>
<div><font style="color:#333333"><i>></i></font></div>
<div><font style="color:#333333"><i><br>
</i></font></div>
</div></div></div>
</div>
</blockquote></div><br></div>