On June 22, 2019 6:10:15 PM GMT+02:00, Marc Glisse <marc.gli...@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.gli...@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.