[PATCH] D31276: Add #pragma clang fast_math

[Adam Nemet via Phabricator via cfe-commits]

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