anemet added a comment. In https://reviews.llvm.org/D31276#710608, @hfinkel wrote:
> In https://reviews.llvm.org/D31276#709111, @anemet wrote: > > > In https://reviews.llvm.org/D31276#708992, @hfinkel wrote: > > > > > High-level comment ;) > > > > > > #pragma clang fast_math contract_fast(on) > > > > > > > > > This seems a bit unfortunate because 'fast' appears twice? How are we > > > planning on naming the other fast-math flags? Maybe we should just name > > > it: > > > > > > This is just pure laziness on my part, I was hoping that all these flags > > can be implemented with on/off but if you find it confusing that's a good > > indicator. > > > > > > > > > > > #pragma clang math constract_fast(on) > > > > > > > > > or > > > > > > #pragma clang math contract(fast) // we could also accept off/on here > > > for consistency and compatibility with the standard pragma > > > > > > > > > or maybe fp_math or floating_point_math or floating_point or fp instead > > > of math. > > > > > > I think that I prefer this last form (because it does not repeat 'fast' > > > and also makes our extension a pure superset of the standard pragma). > > > > > > What do you want to name the other flags? I'd prefer if they're > > > grammatically consistent. Maybe we should stick closely to the > > > command-line options, and have: > > > > > > fp_contract(on/off/fast) > > > unsafe_optimizations(on/off) > > > finite_only(on/off) > > > > > > > > > What do you think? > > > > I really like #pragma clang fp or fp_math because contraction feels > > different from the other fast-math flags. That said then we don't want to > > repeat fp in fp_contract. > > > > We should probably have the full list to make sure it works though with all > > the FMFs. Here is a straw-man proposal: > > > > UnsafeAlgebra #pragma clang fp unsafe_optimizations(on/off) > > NoNaNs #pragma clang fp no_nans(on/off) > > NoInfs #pragma clang fp finite_only(on/off) > > NoSignedZeros #pragma clang fp no_signed_zeros(on/off) > > AllowReciprocal #pragma clang fp reciprocal_math > > AllowContract #pragma clang fp contract(on/off/fast) > > > > > > The negative ones feel a bit strange... What do you think? > > > I agree. The negative ones feel a bit strange. Why should we have no_nans(on) > instead of nans(off)? However, I feel that the negative sense is less > ambiguous - they better match how I think about it and makes a strict > environment one where all of these are 'off', and I like that consistency. In > short, I like this proposal. Great, thanks! I'll update the patch tonight. https://reviews.llvm.org/D31276 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
