[cfe-commits] [llvm-commits] [PATCH] Add llvm.fmuladd intrinsic.

[Chandler Carruth]

On Tue, Jun 5, 2012 at 2:15 PM, Stephen Canon <scanon at apple.com> wrote:

> On Jun 5, 2012, at 1:51 PM, Chandler Carruth <chandlerc at google.com> wrote:
>
> > Trying to at least do my homework, as I'm not usually working w/
> numerics, I've been reading up.
> >
> > 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.
>
> 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!)
>
> 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.
>

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.


> > 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:
>
> Perversely, a strict reading of C++11 seems (to me) to not allow FMA
> formation in C++ at all:
>
>        • 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.
>
> 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).
>

Hmm, good point about the error vs. the precision. Very interesting.

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.

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.

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.
>

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?

Are you imagining something completely different?


> 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.
>

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20120605/fbd7e7a8/attachment.html>