andrew.w.kaylor added inline comments.
================ Comment at: clang/docs/LanguageExtensions.rst:3152 +rounding mode. This option is experimental; the compiler may ignore an explicit +rounding mode in some situations. + ---------------- sepavloff wrote: > andrew.w.kaylor wrote: > > You should say something about whether the rounding mode is applied or > > assumed. The rounding mode argument in the constrained FP intrinsics is > > assumed. The compiler is not required to do anything to force the hardware > > into that rounding mode. I think we want that behavior here as well. I > > believe this follows the semantics of the STDC FENV_ROUND pragmas that were > > introduced by ISO TS-18661. > Hm. I understood the proposal as if pragma FENV_ROUND is applied. If I am > wrong, and that pragma is only a hint to compiler, it is not suitable for our > purposes. We need a mean to generate constrained intrinsics from C/C++ code. > it would facilitate adaptation of LLVM passes for specific floating point > options, including rounding, exception behavior, FENV_ACCESS an so on. It > also would allow users to tune code generation. In this case `pragma > FENV_ROUND` is a different functionality, which should be developed > separately. Sorry, I didn't mean to introduce confusion by bringing up FENV_ROUND, and after reading the description you linked on the other review I'm not sure it does what I was previously told it would anyway. Let's ignore that and just talk about what you're intending to do here. If you only generate constrained intrinsics and do not generate an explicit rounding mode control change instruction (such as a call to fesetround) then the declared rounding mode may not actually be used. According to the definition in the LLVM Language Reference, when you set a rounding mode in a constrained FP intrinsic, the optimizer will assume that rounding mode is in effect and it may use it to perform transformations like constant folding. However, there is no requirement for the compiler to generate code (in response to the constrained intrinsic) to set the rounding mode. Architectures that encode the rounding mode in the instructions may use the rounding mode information (though the LLVM back end isn't currently well structured to enable that), but in cases where the rounding mode is controlled by processor state, the constrained intrinsic will not change it. Hopefully that clarifies what I was asking about here. Do you intend for use of these pragmas to actually change the rounding mode or merely describe it? If the pragmas are intended to change the rounding mode, you will need to generate instructions to do that. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D65997/new/ https://reviews.llvm.org/D65997 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
