Start implementing -frounding-math

[Richard Biener]

On June 22, 2019 6:10:15 PM GMT+02:00, Marc Glisse <marc.glisse@inria.fr> wrote:
>Hello,
>
>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.
>
>Some key missing things:
>- handle C, not just C++ (I don't care, but some people probably do)

As you tackle C++, what does the standard say to constexpr contexts and FENV? That is, what's the FP environment at compiler - time (I suppose FENV modifying functions are not constexpr declared). 

>- handle vectors (for complex, I don't know what it means)
>
>Then flag_trapping_math should also enable this path, meaning that we 
>should stop making it the default, or performance will suffer.

Do we need N variants of the functions to really encode FP options into the IL and thus allow inlining of say different signed-zero flag functions?

I didn't look at the patch but I suppose you rely on RTL to not do code motion across FENV modifications and not fold
Constants? That is, don't we really need unspec_volatile variant patterns for the 
Operations? 

Thanks for working on this. 

Richard. 

>Nice to have:
>- parse the fenv_access pragma and make it set flag_rounding_math or
>similar.
>- sqrt
>
>All the optimizations can come later (I count having different
>functions 
>for flag_rounding_math and flag_trapping_math as one such
>optimization).
>
>
>I put the lowering in its own pass, because it needs to run at -O0 and 
>there aren't that many passes at -O0 where I could put it. It would 
>probably be better to handle this directly during expansion, but with
>my 
>knowledge of the compiler it was easier to lower it before.
>
>This patch passes bootstrap+regtest on x86_64. I expect it may break a
>few 
>testcases on some targets (arm?) that check that we optimize some
>things 
>even with -frounding-math, but as far as I am concerned those do not
>count 
>as regressions because -frounding-math was never really implemented, so
>I 
>would encourage target maintainers to xfail those for now.
>
>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 ;-)
>
>2019-06-24  Marc Glisse  <marc.glisse@inria.fr>
>
>         PR middle-end/34678
>gcc/cp/
> * typeck.c (cp_build_binary_op): Generate internal functions for float
>         operations with -frounding-math.
>
>gcc/
>         * Makefile.in: Handle new file gimple-lower-fenv.cc.
>         * gimple-lower-fenv.cc: New file.
>* internal-fn.c (expand_FENV_PLUS, expand_FENV_MINUS, expand_FENV_MULT,
>         expand_FENV_DIV): New functions.
>    * internal-fn.def (FENV_PLUS, FENV_MINUS, FENV_MULT, FENV_DIV): New
>         internal functions.
>         * passes.def (pass_lower_fenv): New pass.
>         * tree-pass.h (make_pass_lower_fenv): Declare new function.