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

[John McCall]

On Jun 5, 2012, at 3:04 PM, Chandler Carruth 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.

I'm still not sure why you think this restriction *only* happens when round-tripping through casts, rather than through any thing which is not an operand or result, e.g. an object.

Remember that the builtin operators are privileged in C++ — they are not semantically like calls, even in the cases where they're selected by overload resolution.

I agree that my interpretation implies that a type which merely wraps a double nonetheless forces stricter behavior.  I also agree that this sucks.

John.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20120605/f55d319c/attachment.html>