kpn added a comment. >> On targets that support static rounding mode (like RISCV) dynamic and >> constant rounding modes may be different and the behavior changes if default >> mode is replaced by dynamic. > > Whether a target supports static rounding modes on floating-point > instructions is completely irrelevant. The user-visible behavior must be the > same either way. If a target doesn't have specialized instructions, the code > generator can save/restore the rounding mode. This should be transparent to > the user; the user can't read the rounding mode in between the save and > restore. (We already do this sort of rounding mode manipulation on x86, to > implement float-to-int conversion on targets without SSE.)
The rounding mode argument to the constrained intrinsic is a hint; it tells the intrinsic what rounding mode has been set via the normal rounding mode changing mechanism. Constrained intrinsics don't change the rounding mode. I guess we could weaken that by adding "... except if absolutely required" to account for the float-to-int sans SSE case, but the principle applies. Because of the requirement that the rounding mode be changed already, I don't see how instructions with static rounding modes are generally interesting. Perhaps a target will learn to recognize that a sequence of instructions can use the static rounding in the instructions and elide a change of rounding mode around the sequence? I don't know how common that would be in practice. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D126364/new/ https://reviews.llvm.org/D126364 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
