On Fri, 30 Sep 2011, Richard Henderson wrote: > Specifically, in-compiler support for #pragma STDC FENV_ACCESS and the > various <fenv.h> routines. We ought to be able to track the rounding > mode (and other relevant parameters) on a per-expression basis, tagging > each floating-point operation with the parameters in effect.
For C99 and C1X it's just dynamic rounding direction (changed by fesetround, possibly changed by calls to any non-pure function unless you can prove that function doesn't call fesetround, but the default mode can be presumed unless -frounding-math or the FENV_ACCESS pragma is in effect). (asms accessing the relevant registers also need to be considered.) N1582 (status report on the C bindings for IEEE 754-2008) mentions static rounding direction support but doesn't go into details. (Practically, static rounding directions are more useful for various floating-point algorithms.) Floating-point operations implicitly read the rounding mode. They implicitly write the exception flags (as, again, do most function calls) - except that generally they only set rather than clearing flags (but function calls may also call functions that clear them). The present defaults are -fno-rounding-math -ftrapping-math. I'm not sure that with a proper implementation this would really allow much more optimization than -frounding-math -ftrapping-math. Simply enabling exceptions should disable most constant folding where the result isn't exactly representable, because the "inexact" exception is required, for example; just knowing the rounding mode and so the value of the result isn't enough to fold. And if there aren't any function calls intervening, all combinations of these options will allow common subexpression elimination (since that doesn't change the set of exceptions raised, and no support is required for counting the number of times a particular exception was raised). So the right defaults once -ftrapping-math really does what it says aren't clear. I've thought a bit about implementation approaches, but mainly at the level of how to decouple the front-end and back-end parts from the full complexity of tracking pragma state for each expression (for example, by setting variables on a whole-function basis and restricting inlining). I've also thought about how to implement testcases providing reasonably thorough coverage of the exceptions and rounding modes issues. But I haven't had time to work on implementation of any of these pieces. -- Joseph S. Myers jos...@codesourcery.com
