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

[Serge Pavlov via Phabricator via cfe-commits]

sepavloff added a comment.

In D156989#4558134 <https://reviews.llvm.org/D156989#4558134>, @arsenm wrote:

> In D156989#4558133 <https://reviews.llvm.org/D156989#4558133>, @sepavloff wrote:
>
>> Rounding mode is presented in FPOptions with 3 bits, so there is only 8 values available for particular modes. 5 of them, which are specified in IEEE-754, are listed in `RoundingMode`. `Dynamic` (which is -1 in 3-bit numbers) is not a real rounding mode,
>
> But it is a spec'd value as -1 for FLT_ROUNDS

It is no more than failure indicator for this function or macro. `fegetround` may use any negative value for this purpose. -1 does not represent any rounding mode, just like EOF does not represent any character in a stream.

>> Probably `Dynamic` is what you need. It prevents from constant folding and other transformations that rely on particular rounding mode and does not restrict actual rounding modes used in runtime. What  prevents from using this mode for your case?
>
> I can do better by reporting something meaningful, two different modes is not unknown. The enum here should just be exactly equal to the FLT_ROUNDS values and not pick a random other number, I just need the wrong value for Dynamic to get out of the way to avoid creating additional wrappers

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.

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.

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.


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

https://reviews.llvm.org/D156989