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 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
