I've lost track of this thread. Is there strong objection to the proposal? Is there a concrete alternative proposal? We're looking for a reasonable intermediate solution to allows progress.
Evan On Jun 5, 2012, at 3:35 PM, John McCall wrote: > 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. > _______________________________________________ > llvm-commits mailing list > [email protected] > http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
