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