Page MenuHomePhabricator

[Clang] Use pragma FENV_ROUND to reset rounding mode settings.
Needs ReviewPublic

Authored by sepavloff on Aug 1 2022, 8:16 AM.



Now starting from the first use of pragma FENV_ROUND rounding mode
becomes user-defined and there is no way to return back to initial
state. Default rounding mode and the same explicitly defined one result
in different AST. For example, the code:

float func_04(float x, float y) {
  return x + y;

produces AST where the FP operation is represented with the node:

`-BinaryOperator 0x25d6e2cecb8 <col:10, col:14> 'float' '+'

The same code with #pragma STDC FENV_ROUND FE_TONEAREST before the
function definition produces slightly different representation:

`-BinaryOperator 0x1832c1a4ce8 <col:10, col:14> 'float' '+' ConstRoundingMode=tonearest

Code generation is not changed in this case because tonearest is the
rounding mode in default FP environment. However if an AST object has
an override for a FP property, it considered as explicitly specified
and is preserved in some cases where default property may be overridden.

Default rounding mode is dynamic according to the C2x standard
draft (7.6.2p3):

... If no FENV_ROUND pragma is in effect, or the specified constant
rounding mode is FE_DYNAMIC, rounding is according to the mode
specified by the dynamic floating-point environment ...

So pragma FENV_ROUND FE_DYNAMIC must reset rounding to default state,
but now it only adds related override:

`-BinaryOperator 0x1cb8cfaaec8 <col:10, col:14> 'float' '+' ConstRoundingMode=dynamic

This change fixes the pragma behavior. If FENV_ROUND FE_DYNAMIC is
specified without FENV_ACCESS ON, the rounding mode override is
removed, which effectively establish default rounding mode state.

Diff Detail

Event Timeline

sepavloff created this revision.Aug 1 2022, 8:16 AM
Herald added a project: Restricted Project. · View Herald TranscriptAug 1 2022, 8:16 AM
sepavloff requested review of this revision.Aug 1 2022, 8:16 AM
Herald added a project: Restricted Project. · View Herald TranscriptAug 1 2022, 8:16 AM
efriedma added inline comments.Aug 4 2022, 11:40 AM

I'm not really happy with the way this is written... like I mentioned in the other patch, keep the state transitions simple, and put the logic into the code that computes the derived properties.

sepavloff added inline comments.Aug 5 2022, 9:38 AM

This is not about any floating-point property, it is only how to distinguish between the cases of user-defined properties (which must be preserved) and default ones (which may be overridden). So far the only case, where this difference is important, is the interaction of FP pragmas and template instantiations, implemented in D131143. If that change is not accepted, this one loses its value.