As such this has nothing to do with the constrained intrinsics. The constrained intrinsics and strictfp are specifically for dealing with the dynamic mode and fp exceptions.
Does this mean that static rounding should use their own representation in IR? What about using operations with static rounding if strict exception handling is needed? They should use constrained intrinsics but cannot due to static rounding.
The intent of these intrinsics was the compiler does not need to insert code to manage the rounding mode. It’s expressing what the user set the known rounding mode to.
I would expect that these ittrinsics express side effect caused by reading control modes and setting exception flags. Static rounding removes dependency on some bits in control register but still affects exception.
IMO these hints are kind of useless and we’re not doing anything with them.
They acquire meaning if are used to represent static rounding. Otherwise yes, they are useless, if compiler even cannot rely on them:
the actual runtime rounding mode (as defined in a target-specific manner) matches the specified rounding mode, but this is not guaranteed.
A set of intrinsics with a constant rounding argument, like we already have in llvm.fptrunc.round.
It means a new representation for FP operations, different from constrained intrinsics, but also limited. And the case with static rounding but strict exception handling is also not covered. I would like to reuse the existing mechanism if possible.
The best case would be instructions that list accessed resources with access type, as was discussed in Thought on strictfp support - #7 by arsenm but it is a distant future.