On Sat, 22 Jun 2019, Marc Glisse wrote: > as discussed in the PR, this seems like a simple enough approach to handle > FENV functionality safely, while keeping it possible to implement > optimizations in the future.
Could you give a high-level description of the implementation approach, and how this design is intended to (eventually) achieve the required constraints on code movement and removal? In <https://gcc.gnu.org/ml/gcc/2013-01/msg00095.html> I listed those constraints as: * General calls may set, clear or test exceptions, or manipulate the rounding mode (as may asms, depending on their inputs / outputs / clobbers). * Floating-point operations have the rounding mode as input. They may set (but not clear or test) floating-point exception flags. * Thus in general floating-point operations may not be moved across most calls (or relevant asms), or values from one side of a call reused for the same operation with the same inputs appearing on the other side of the call. * Statements such as "(void) (a * b);" can't be eliminated because they may raise exceptions. (That's purely about exceptions, not rounding modes.) (I should add that const function calls should not depend on the rounding mode, but pure calls may. Also, on some architectures there are explicit register names for asms to use in inputs / outputs / clobbers to refer to the floating-point state registers, and asms not referring to those can be taken not to manipulate floating-point state, but other architectures don't have such names. The safe approach for asms would be to assume that all asms on all architectures can manipulate floating-point state, until there is a way to declare what the relevant registers are.) (I should also note that DFP has a separate rounding mode from binary FP, but that is unlikely to affect anything in this patch - although there might end up being potential minor optimizations from knowing that certain asms only involve one of the two rounding modes.) > I'd like to handle this incrementally, rather than wait for a mega-patch that > does everything, if that's ok. For instance, I didn't handle vectors in this > first patch because the interaction with vector lowering was not completely > obvious. Plus it may help get others to implement some parts of it ;-) Are there testcases that could be added initially to demonstrate how this fixes cases that are currently broken, even if other cases aren't fixed? -- Joseph S. Myers jos...@codesourcery.com
