<div class="gmail_quote">On Tue, Jun 5, 2012 at 2:15 PM, Stephen Canon <span dir="ltr"><<a href="mailto:scanon@apple.com" target="_blank">scanon@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On Jun 5, 2012, at 1:51 PM, Chandler Carruth <<a href="mailto:chandlerc@google.com">chandlerc@google.com</a>> wrote:<br>
<br>
> Trying to at least do my homework, as I'm not usually working w/ numerics, I've been reading up.<br>
><br>
> I've now read the FP_CONTRACT part of the C11 spec, and see where your statement comes from. I find this restriction... mysterious. I would love to understand why it is important to prevent inlining from exposing contraction opportunities if you can give any examples.<br>

<br>
</div>Largely it's for historical reasons; there is a lot of existing code that expects operations spanning expressions to not be contracted.  It's critical to be able to forbid FMA formation for some computations, and some people happen to have written code in this style (probably because they, too, hate pragmas!)<br>

<br>
If I remember right, Jim Thomas at HP was involved in the design of FP_CONTRACT in C99; I'll ask him if he can provide a clearer rationale if you're really interested.<br></blockquote><div><br></div><div>Interesting.... While I'm vaguely interested, I suspect the list is not... and we both probably have better things to dig through than this archaeology. Thanks for this much background though.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">> That said, FP_CONTRACT doesn't apply to C++, and it's quite unlikely to become a serious part of the standard given these (among other) limitations. Curiously, in C++11, it may not be needed to get the benefit of fused multiply-add:<br>

<br>
</div>Perversely, a strict reading of C++11 seems (to me) to not allow FMA formation in C++ at all:<br>
<br>
        • The values of the floating operands and the results of floating expressions may be represented in greater precision and range than that required by the type; the types are not changed thereby.<br>
<br>
FMA formation does not increase the precision or range of the result (it may or may not have smaller error, but it is not more precise), so this paragraph doesn't actually license FMA formation.  I can't find anywhere else in the standard that could (though I am *far* less familiar with C++11 than C11, so I may not be looking in the right places).<br>
</blockquote><div><br></div><div>Hmm, good point about the error vs. the precision. Very interesting.</div><div><br></div><div>Anyways, C++, whenever it decides to move forward with something like allowing (or disallowing) contraction and similar transforms, will almost certainly not be willing to accept the same source-expression restriction that C11 did given operator overloading. I'd really like to figure out what a good FE -> BE interface for this is in the long term.</div>
<div><br></div><div>Let me be clear: Lang's existing proposal seems a fine way to cut in minimal support for FP_CONTRACT, but it doesn't look like something we'd want to use more broadly. I'm not really worried with the interim solution(s), I'm trying to figure out what the end-goal is here.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">The trouble I see with this is that you're going to end up generating an enormous number of start/stop intrinsics for some code (one pair for every source expression containing FP, effectively).  I'm not sure how much of a concern that really is, but it feels inelegant to me.</div>
</blockquote><div><br></div><div>My idea was essentially that you would only do this where contraction was precluded, which you indicated should be rare (1%). That should restrict the amount of start/stop churn?</div><div>
<br></div><div>Are you imagining something completely different?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">It's worth remembering in all of this that we also want to (/will) have a third "fast math" mode of operation in which greedy FMA formation is licensed, regardless of the provenance of the fmul and fadd that are fused.  That doesn't need any front-end involvement, however, so that's outside the scope of the changes that Lang has prepared.<br>
</blockquote><div><br></div><div>Agreed on both the need for this and the scope. I'm looking to get a good solution for the mode you described: 99% of operations are viable for fusing, 1% aren't.</div></div>