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

[Chandler Carruth]

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

> On Jun 5, 2012, at 2:45 PM, John McCall <rjmccall at apple.com> wrote:
>
> > On Jun 5, 2012, at 2:15 PM, Stephen Canon wrote:
> >
> >> On Jun 5, 2012, at 1:51 PM, Chandler Carruth <chandlerc at google.com>
> wrote:
> >>
> >>> 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).
> >
> > Correct me if I'm wrong, but I thought that an FMA could be formalized
> as representing the result of the multiply with greater precision than the
> operation's type actually provides, and then using that as the operand of
> the addition.  It's understand that that can change the result of the
> addition in ways that aren't just "more precise".  Similarly, performing
> 'float' operations using x87 long doubles can change the result of the
> operation, but I'm pretty sure that the committees explicitly had hardware
> limitations like that in mind when they added this language.
>
> That's an interesting point.  I'm inclined to agree with this
> interpretation (there are some minor details about whether or not 0*INF +
> NAN raises the invalid flag, but let's agree to ignore that).
>
> I'm not familiar enough with the language used in the C++ spec to know
> whether this makes C++ numerics equivalent to STDC FP_CONTRACT on, or
> equivalent to "allow greedy FMA formation".  Anyone?
>

If you agree w/ John's interpretation, and don't consider the flag case you
mention, AFAICT, this allows greedy FMA formation, unless the intermediate
values are round-tripped through a cast construct such as I described.

It definitely doesn't match STDC FP_CONTRACT ON as there is no special
status granted due to the expressions being written in different source
statements.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20120605/e2b36cdc/attachment.html>