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

[Chandler Carruth]

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

> On Jun 5, 2012, at 3:04 PM, Chandler Carruth <chandlerc at google.com> wrote:
>
> 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.
>
>
> So C++ provides no means to forbid FMA formation (other than possibly a
> gratuitous cast on the result of the multiply)?  That's unfortunate in the
> extreme.
>

It is very easy to write a library that uses these casts to implement
strict rules.

(I may even now be roped into proposing such a library for the standard,
which will remove the hack of doing gratuitous casts, and provide a
standards-blessed way of saying that operations on that 'strict_fp<float>'
type (or whatever it's called) are not subject to these types of
optimizations.)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20120605/dc551034/attachment.html>