On Jun 5, 2012, at 3:04 PM, Chandler Carruth wrote:
> On Tue, Jun 5, 2012 at 2:58 PM, Stephen Canon <[email protected]> wrote:
> On Jun 5, 2012, at 2:45 PM, John McCall <[email protected]> wrote:
>
> > On Jun 5, 2012, at 2:15 PM, Stephen Canon wrote:
> >
> >> On Jun 5, 2012, at 1:51 PM, Chandler Carruth <[email protected]> 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.
_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
