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

Chandler Carruth chandlerc at google.com
Tue Jun 5 14:31:35 PDT 2012

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>

More information about the cfe-commits mailing list