scanon added a comment. In D113107#3138671 <https://reviews.llvm.org/D113107#3138671>, @rjmccall wrote:
>> Basically agree with everything John said, with a note that #3 is not quite >> FP_CONTRACT, which allows evaluating an expression as if intermediate steps >> were infinitely-precise, but rather FLT_EVAL_METHOD == 32 as defined in >> ISO/IEC TS 18661-3: "evaluate operations and constants, whose semantic type >> has at most the range and precision of the _Float32 type, to the range and >> precision of the _Float32 type; evaluate all other operations and constants >> to the range and precision of the semantic type". > > Ah, thank you, I wasn't aware that the intent was for FP_CONTRACT to only > allow evaluation as if infinitely precise. That's much more limited; > wouldn't it preclude things like doing `float` arithmetic with `double`-only > hardware, or with the x87 operations without intermediate rounding? Yes; the C definition of "contracted" is "A floating expression may be contracted, that is, evaluated as though it were a single operation, thereby omitting rounding errors implied by the source code and the expression evaluation method." All the things you mention are covered by FLT_EVAL_METHOD, except that it can't actually represent all the combinations that one might choose to implement because it's a single scalar value. E.g. when targeting no-sse2, one might want to evaluate _Float16 and float using SSE, but double and long double (80-bit) using x87. There's no way to express those semantics. Fortunately, that's the only combination that I can think of someone wanting to use that's not expressible, and it's rather niche. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D113107/new/ https://reviews.llvm.org/D113107 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
