[PATCH] D156989: FloatingPointMode: Use -1 for "Dynamic"

[Matt Arsenault via Phabricator via cfe-commits]

arsenm added a comment.

In D156989#4558486 <https://reviews.llvm.org/D156989#4558486>, @sepavloff wrote:

> Support of rounding mode in C standard is based on IEEE-754 model, where rounding mode is a global state and affects all FP operations. The case of two rounding modes does not fit this model. So in C/C++ you anyway need to invent special tools for setting this or that rounding mode or reading them. If static rounding mode is not needed, IEEE-754 rounding mode could be represented by `Dynamic` value.

Correct, I'm not planning on creating special "standard looking" tools. I just want the value in the target defined range rather than a black box.

> In IR there are more possibilities to represent many rounding modes. Each constrained intrinsic call contains rounding mode and that mode may be different for different FP types. Actually this model can support the general case. For example, rounding mode for one type can be static but for the other type it can be dynamic. There must be intrinsic functions that set/get rounding mode for different types.

The raw target intrinsic to read the mode register works. Once you're in the target range you know you have to do something with target operations

> It looks like adding special bultin functions to get/set rounding mode for different types is enough to support rounding in AMDGPU. In any case IEEE-754 rounding mode should be honored, which means that `fegetround` and `FLT_ROUNDS` probably should return negative value, and `fesetround` probably should set all rounding modes. The difference between `Dynamic` and -1 does not matter because `Dynamic` can never be an argument of rounding mode type and `Invalid` (-1) is an error indicator and must not be treated as rounding mode.

My interpretation is fesetround of standard values would set all modes to be the same. Once you're outside of the range  it would work correctly to consume the same target defined values. "Could not determine" is the same as dynamic, so this should just use the standard -1 value instead of 7 just to fit in a clang bitfield


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D156989/new/

https://reviews.llvm.org/D156989