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.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
- Build Status
Buildable 36504 Build 36503: arc lint + arc unit
Event Timeline
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. |
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: |
clang/lib/Parse/ParsePragma.cpp | ||
---|---|---|
2697 | This case is different from the above, the list of expected arguments depend on the current option. |
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? |
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. |
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. |
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? |
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. |
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."