efriedma added a comment. The way I see it, there are two possibilities here:
1. In Sema, we have two rounding modes that correspond to FE_DYNAMIC: llvm::RoundingMode::Dynamic, and llvm::RoundingMode::NearestTiesToEven, plus some boolean to indicate whether the user actually explicitly specified FE_TONEAREST. (You're currently missing the boolean, which means that currently "#pragma STDC FENV_ACCESS OFF" followed by "#pragma STDC FENV_ACCESS ON" actually mutates the rounding mode.) We juggle the rounding modes and the bit based on whether FENV_ACCESS is currently enabled. 2. We just have one rounding mode in Sema that corresponds to FE_DYNAMIC. Then in CodeGen, we set the actual rounding mode based on whether FENV_ACCESS is currently enabled. (2) seems a lot simpler. > 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.) 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
