hfinkel added a comment. In https://reviews.llvm.org/D53157#1304873, @cameron.mcinally wrote:
> In https://reviews.llvm.org/D53157#1304275, @kpn wrote: > > > In https://reviews.llvm.org/D53157#1303398, @cameron.mcinally wrote: > > > > > If we all agree upon that, then we simply have to treat the functions > > > that modify the FPEnv, e.g. fesetexcept(...), as barriers. That way it > > > does not matter if a FENV_ACCESS=OFF function is translated with > > > constrained intrinsics or not, since nothing can be scheduled around > > > these barriers. > > > > > > I thought we couldn't do barriers. No barriers means no way to prevent code > > motion and mixing of constrained with non-constrained FP. That was the > > reason for having all FP in a function be constrained if any of it was. > > > I'd like to hear more about this. The fesetexcept(...) function and friends > change the FPEnv state, which can change the semantics for the instructions > that follow. They definitely have to act as a barrier. There's no sense in which we can have a code-motion barrier within a function that acts on the regular FP instructions. We can have a barrier for the constrained intrinsics. This is why we need, in this design, for any function that uses FENV_ACCESS=ON for any part of it, to always use the constrained instrinsics. https://reviews.llvm.org/D53157 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
