On Tue, Jun 5, 2012 at 2:15 PM, Stephen Canon <[email protected]> wrote:
> On Jun 5, 2012, at 1:51 PM, Chandler Carruth <[email protected]> wrote: > > > Trying to at least do my homework, as I'm not usually working w/ > numerics, I've been reading up. > > > > I've now read the FP_CONTRACT part of the C11 spec, and see where your > statement comes from. I find this restriction... mysterious. I would love > to understand why it is important to prevent inlining from exposing > contraction opportunities if you can give any examples. > > Largely it's for historical reasons; there is a lot of existing code that > expects operations spanning expressions to not be contracted. It's > critical to be able to forbid FMA formation for some computations, and some > people happen to have written code in this style (probably because they, > too, hate pragmas!) > > If I remember right, Jim Thomas at HP was involved in the design of > FP_CONTRACT in C99; I'll ask him if he can provide a clearer rationale if > you're really interested. > Interesting.... While I'm vaguely interested, I suspect the list is not... and we both probably have better things to dig through than this archaeology. Thanks for this much background though. > > 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). > Hmm, good point about the error vs. the precision. Very interesting. Anyways, C++, whenever it decides to move forward with something like allowing (or disallowing) contraction and similar transforms, will almost certainly not be willing to accept the same source-expression restriction that C11 did given operator overloading. I'd really like to figure out what a good FE -> BE interface for this is in the long term. Let me be clear: Lang's existing proposal seems a fine way to cut in minimal support for FP_CONTRACT, but it doesn't look like something we'd want to use more broadly. I'm not really worried with the interim solution(s), I'm trying to figure out what the end-goal is here. The trouble I see with this is that you're going to end up generating an > enormous number of start/stop intrinsics for some code (one pair for every > source expression containing FP, effectively). I'm not sure how much of a > concern that really is, but it feels inelegant to me. > My idea was essentially that you would only do this where contraction was precluded, which you indicated should be rare (1%). That should restrict the amount of start/stop churn? Are you imagining something completely different? > It's worth remembering in all of this that we also want to (/will) have a > third "fast math" mode of operation in which greedy FMA formation is > licensed, regardless of the provenance of the fmul and fadd that are fused. > That doesn't need any front-end involvement, however, so that's outside > the scope of the changes that Lang has prepared. > Agreed on both the need for this and the scope. I'm looking to get a good solution for the mode you described: 99% of operations are viable for fusing, 1% aren't.
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
