arsenm added a comment. In D142907#4119339 <https://reviews.llvm.org/D142907#4119339>, @andrew.w.kaylor wrote:
> In general, it seems like the denormal mode should be considered part of the > floating point environment (though as far as I know the C standard, at least, > doesn't document it as such). There’s no standardization of denormal flushing. OpenCL defines a flag for it but doesn’t really specify what it really means. > If it were considered part of the floating point environment, the LLVM rules > would tell us we could assume the default setting, which I'd assume to be > IEEE, and it would only be legal to change this mode in strict mode. It is. The attribute is informative of the default mode. If we really wanted, a similar attribute could declare the assumed rounding mode if we really wanted for the function. It doesn’t imply you can change it dynamically, just that it should be in that mode before the function executes. > Do you need to do something with the inliner to handle the case where > functions with different denormal modes are inlined into one another? We > don't seem to handle that case correctly now > (https://godbolt.org/z/PEsWaMEq6), but with the dynamic mode we could handle > it without blocking inlining completely. This patch fixed some bugs in the inlining to make it more conservative in undefined looking cases. The inlining of dynamic functions fully works CHANGES SINCE LAST ACTION https://reviews.llvm.org/D142907/new/ https://reviews.llvm.org/D142907 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
