andrew.w.kaylor added a comment. In https://reviews.llvm.org/D53157#1291978, @cameron.mcinally wrote:
> In https://reviews.llvm.org/D53157#1291964, @kpn wrote: > > > I don't expect anyone would need to switch between constrained and regular > > floating point at an instruction level of granularity. > > > The Standard allows for this (to some degree). E.g. FENV_ACCESS can be > toggled between nested compound statements. > > Also, some AVX512 hardware instructions have explicit SAE and RM operands. Just because FENV_ACCESS can be toggled on that granularity doesn't mean we have to represent it that way. We've previously agreed (I think) that if FENV_ACCESS is enabled anywhere in a function we will want to use the constrained intrinsics for all FP operations in the function, not just the ones in the scope where it was specified. I think this works because FENV_ACCESS ON needs to be respected (i.e. we need to assume that the user may change the FP environment) but FENV_ACCESS OFF doesn't need to be respected (i.e. we are not required to assume that the user will not change the environment). For instance, the spec does give us liberty to assume the default rounding mode in FENV_ACCESS OFF regions, but if we make no assumptions about the rounding mode that will be conservatively correct. As for instructions that take an explicit rounding mode argument, that's a separate issue (and one that is relevant for multiple architectures). The constrained intrinsics do not enforce a rounding mode (i.e. they are descriptive rather than prescriptive), but if we have concrete rounding mode arguments for any given instruction we could use that to encode the rounding mode in the instruction. I'm not sure how user code would express this apart from use of intrinsics. https://reviews.llvm.org/D53157 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
