This is an archive of the discontinued LLVM Phabricator instance.

Add #pragma clang fp
ClosedPublic

Authored by anemet on Mar 22 2017, 10:47 PM.

Details

Summary

This adds the new pragma and the first variant, contract(on/off/fast).

The pragma has the same block scope rules as STDC FP_CONTRACT, i.e. it can be
placed at the beginning of a compound statement or at file scope.

Similarly to STDC FP_CONTRACT there is no need to use attributes. First an
annotate token is inserted with the parsed details of the pragma. Then the
annotate token is parsed in the proper contexts and the Sema is updated with
the corresponding FPOptions using the shared ActOn function with STDC
FP_CONTRACT.

After this the FPOptions from the Sema is propagated into the AST expression
nodes. There is no change here.

I was going to add a 'default' option besides 'on/off/fast' similar to STDC
FP_CONTRACT but then decided against it. I think that we'd have to make option
uppercase then to avoid using 'default' the keyword. Also because of the
scoped activation of pragma I am not sure there is really a need a for this.

Diff Detail

Repository
rL LLVM

Event Timeline

anemet created this revision.Mar 22 2017, 10:47 PM
davide added a subscriber: davide.Mar 23 2017, 12:30 AM
aaron.ballman added inline comments.Mar 23 2017, 9:07 AM
docs/LanguageExtensions.rst
2319 ↗(On Diff #92759)

Missing "pragma" in front of "allows".

2320 ↗(On Diff #92759)

Remove double spaces (applies elsewhere).

2321 ↗(On Diff #92759)

By "start of a compound statement", does that include or exclude things like comments? e.g., is this valid?

{
  // Disable clang's fast-math
  #pragma clang fast_math contract_fast(off)
}
2325 ↗(On Diff #92759)

Comma after Currently.

anemet updated this revision to Diff 92825.Mar 23 2017, 9:46 AM
anemet marked 4 inline comments as done.

Address Aaron's comments. Also add a code example to the documentation.

anemet added inline comments.Mar 23 2017, 9:47 AM
docs/LanguageExtensions.rst
2321 ↗(On Diff #92759)

Excluding comments. Added the words.

FTR, there is also test coverage for this already in the patch.

This revision is now accepted and ready to land.Mar 23 2017, 10:12 AM

Thanks very much, Aaron! It would be great if you could also look at the three patches that add support for the generation of the new FMF 'contract' for -ffp-contract=fast. I've added them in the dependencies of this revision. (D31168 is not really a prerequisite but I am planning to commit the patches in this order.)

Thanks very much, Aaron! It would be great if you could also look at the three patches that add support for the generation of the new FMF 'contract' for -ffp-contract=fast. I've added them in the dependencies of this revision. (D31168 is not really a prerequisite but I am planning to commit the patches in this order.)

I'll take a look, but feel less qualified to give a LGTM to those.

hfinkel edited edge metadata.Mar 23 2017, 10:36 AM

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:

#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?

Thanks very much, Aaron! It would be great if you could also look at the three patches that add support for the generation of the new FMF 'contract' for -ffp-contract=fast. I've added them in the dependencies of this revision. (D31168 is not really a prerequisite but I am planning to commit the patches in this order.)

I'll take a look, but feel less qualified to give a LGTM to those.

NP, thanks for your help on this one. Hopefully @hfinkel or @mehdi_amini can take a look.

Thanks very much, Aaron! It would be great if you could also look at the three patches that add support for the generation of the new FMF 'contract' for -ffp-contract=fast. I've added them in the dependencies of this revision. (D31168 is not really a prerequisite but I am planning to commit the patches in this order.)

I'll take a look, but feel less qualified to give a LGTM to those.

NP, thanks for your help on this one. Hopefully @hfinkel or @mehdi_amini can take a look.

They're definitely on my list. I might not get to them until the weekend or next week, however.

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?

They're definitely on my list. I might not get to them until the weekend or next week, however.

Thank you. The schedule is getting tight but that should still work ;).

Actually most of the individual patches are pretty small both in clang and llvm. This one was the one that I felt the least confident about :).

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.

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.

anemet retitled this revision from Add #pragma clang fast_math to Add #pragma clang fp.Mar 28 2017, 5:28 PM
anemet edited the summary of this revision. (Show Details)
anemet updated this revision to Diff 93325.Mar 28 2017, 5:29 PM
anemet retitled this revision from Add #pragma clang fp to Add #pragma clang fast_math.
anemet edited the summary of this revision. (Show Details)

Rename pragma from #pragma clang fast_math contract_fast(on/off) -> #pragma clang fp contract(on/fast/off)

No other functional change.

anemet retitled this revision from Add #pragma clang fast_math to Add #pragma clang fp.Mar 28 2017, 5:30 PM
anemet edited the summary of this revision. (Show Details)

(Sorry about updating the title/description back and forth but arcanist is buggy)

This continues to look good to me with the new name.

This continues to look good to me with the new name.

Thank you, Aaron!

This revision was automatically updated to reflect the committed changes.