This is an archive of the discontinued LLVM Phabricator instance.

Add options rounding and exceptions to pragma fp
Needs ReviewPublic

Authored by sepavloff on Aug 9 2019, 12:28 AM.

Details

Summary

Pragma 'clang fp' is extended to support two new options, 'rounding' and
'exceptions'. They allow to specifying floating point environment more
precisely than '#pragma STDC FENV_ACCESS' does. Syntax of the pragma is
described in LanguageExtensions.rst.
The primary goal of this change is to facilitate development of support
for floating point operations in non-default or dynamic environment.

Event Timeline

sepavloff created this revision.Aug 9 2019, 12:28 AM
Herald added a project: Restricted Project. · View Herald TranscriptAug 9 2019, 12:28 AM
aaron.ballman added inline comments.Aug 9 2019, 5:06 AM
clang/docs/LanguageExtensions.rst
3146

specifies rounding mode -> specifies the rounding mode

3151

The last sentence is a bit ambiguous because "this option" could mean "rounding modes in general" or it could mean "the dynamic rounding mode". I would reword it to:

compiler does not guarantee to process it in all cases -> the compiler may ignore a dynamic rounding mode in some situations

or

compiler does not guarantee to process it in all cases -> the compiler may ignore an explicit rounding mode in some situations

3157

Will this link remain stable?

3158

Same issue here as above, reword similarly.

clang/lib/Parse/ParsePragma.cpp
2670

Given that all of these strings are known at compile time, I would rather see use of a %select in the diagnostic.

2697

Same here.

kpn added inline comments.Aug 9 2019, 8:09 AM
clang/docs/LanguageExtensions.rst
3151

I'd go with the latter, or perhaps "the compiler may ignore the rounding mode setting in some situations."

Currently, sometimes llvm will ignore the setting entirely, other times it will assume dynamic despite the setting being more specific.

Also:
s/assume particular/assume any particular/
s/experimental, compiler/experimental; the compiler/

sepavloff updated this revision to Diff 214750.Aug 12 2019, 6:45 PM

Updated patch

sepavloff marked 7 inline comments as done.Aug 12 2019, 6:50 PM
sepavloff added inline comments.
clang/lib/Parse/ParsePragma.cpp
2697

This case is different from the above, the list of expected arguments depend on the current option.

aaron.ballman added inline comments.Aug 13 2019, 6:13 AM
clang/lib/Parse/ParsePragma.cpp
2697

The case isn't different in the way that matters -- all of the strings that get passed in to the diagnostic come from string literals. You should be able to put the literals into the %select and map TokFPAnnotValue::* to an index, right?

sepavloff updated this revision to Diff 215134.Aug 14 2019, 8:39 AM

Updated patch

sepavloff marked 2 inline comments as done.Aug 14 2019, 8:40 AM
sepavloff added inline comments.
clang/lib/Parse/ParsePragma.cpp
2697

I see, thank you)

This generally LGTM, but there are open questions on https://reviews.llvm.org/D66092#1625380 that I think need to be answered before this should be committed.

clang/lib/Parse/ParsePragma.cpp
2680

Might as well move this down to around line 2710, closer to where it's used. This way we don't allocate something only to ignore it due to errors in fewer situations.

sepavloff marked an inline comment as done.Aug 15 2019, 12:10 AM
sepavloff added inline comments.
clang/lib/Parse/ParsePragma.cpp
2680

Actually it cannot be closer. It is created just before the loop, in which fields of *AnnotValue are read.

aaron.ballman added inline comments.Aug 15 2019, 6:28 AM
clang/lib/Parse/ParsePragma.cpp
2680

Ah, you're right, I didn't see that was inside the loop itself. Nevermind. :-)

clang/docs/LanguageExtensions.rst
3127

This part of the documentation is ambiguous in light of the new options. I suppose "[t]he pragma" here refers to "#pragma clang fp contract" but the first paragraph refers to "#pragma clang fp" as "the pragma."

3152

You should say something about whether the rounding mode is applied or assumed. The rounding mode argument in the constrained FP intrinsics is assumed. The compiler is not required to do anything to force the hardware into that rounding mode. I think we want that behavior here as well. I believe this follows the semantics of the STDC FENV_ROUND pragmas that were introduced by ISO TS-18661.

3159

I'm not sure what this is supposed to mean. What are the circumstances under which the compiler may ignore an explicit exception behavior? Do you mean that it isn't supposed to happen but it might while the feature is under development?

sepavloff marked 2 inline comments as done.Aug 16 2019, 12:08 AM
sepavloff added inline comments.
clang/docs/LanguageExtensions.rst
3152

Hm. I understood the proposal as if pragma FENV_ROUND is applied. If I am wrong, and that pragma is only a hint to compiler, it is not suitable for our purposes. We need a mean to generate constrained intrinsics from C/C++ code. it would facilitate adaptation of LLVM passes for specific floating point options, including rounding, exception behavior, FENV_ACCESS an so on. It also would allow users to tune code generation. In this case pragma FENV_ROUND is a different functionality, which should be developed separately.

3159

The purpose is to have a tool that would allow developing support of constrained nodes in LLVM pipeline. So we discourage using this pragma by end users. Yes, you are right, it means a feature under development.

Since LLVM already has strict FP nodes, i'd personally like to see this RFC to not
discuss "let's add XYZ", but discuss what features it targets to accomplish,
what features are already achievable via strict FP nodes,
and instead of adding a third set of FP operations,
try to propose to extend strict FP nodes,

clang/docs/LanguageExtensions.rst
3152

Sorry, I didn't mean to introduce confusion by bringing up FENV_ROUND, and after reading the description you linked on the other review I'm not sure it does what I was previously told it would anyway. Let's ignore that and just talk about what you're intending to do here.

If you only generate constrained intrinsics and do not generate an explicit rounding mode control change instruction (such as a call to fesetround) then the declared rounding mode may not actually be used. According to the definition in the LLVM Language Reference, when you set a rounding mode in a constrained FP intrinsic, the optimizer will assume that rounding mode is in effect and it may use it to perform transformations like constant folding. However, there is no requirement for the compiler to generate code (in response to the constrained intrinsic) to set the rounding mode. Architectures that encode the rounding mode in the instructions may use the rounding mode information (though the LLVM back end isn't currently well structured to enable that), but in cases where the rounding mode is controlled by processor state, the constrained intrinsic will not change it.

Hopefully that clarifies what I was asking about here. Do you intend for use of these pragmas to actually change the rounding mode or merely describe it? If the pragmas are intended to change the rounding mode, you will need to generate instructions to do that.

qiucf added a subscriber: qiucf.Mar 15 2021, 1:54 AM