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

[Chandler Carruth]

On Tue, 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.


I don't see any specification of the distinction between the precision at
which the operation is performed vs. the precision with which the the
result is held in a register... but...


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

I tend to agree with you. I suspect (without evidence beyond what you cite)
that the committee would have intended this paragraph to allow FMA as well
as x87 instructions.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20120605/aac73944/attachment.html>