Re: Start implementing -frounding-math

[Marc Glisse <marc.glisse@inria.fr>]

On Wed, 7 Aug 2019, Joseph Myers wrote:

> 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,

At the GIMPLE level, z = x + y is represented as a function call z = 
.FENV_PLUS (x, y, options). The floating point environment (rounding mode, 
exceptions) is considered to be somewhere in memory (I think it still 
works if it is a hard register). Unless options say so, .FENV_PLUS may 
read/write to memory. There are very little optimizations that can be done 
on general function calls, so this should avoid unwanted movement or 
removal. We can still implement some specific optimizations just for those 
functions.

At the RTL level, well the idea is that good back-ends would expand 
.FENV_PLUS however they want, but the default is to have the arguments and 
the result use an asm volatile pass-through, which is opaque to optimizers 
and prevents constant propagation, removal, movement, etc.

(the use of "options" is to avoid having many variants depending on 
whether we only care about rounding, exceptions, maybe ignore signed 
zeros, etc, with 0 as the strictest, always-safe version. For explicitly 
rounded operations as with pragma fenv_round, a different function might 
be better since the 0 case is not a safe replacement anymore)

> 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).

If the asm is volatile, this works fine. I'll come back to this below.

> * 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 had to add TREE_SIDE_EFFECTS = 1 so the C++ front-end wouldn't remove it 
prematurely.

> (I should add that const function calls should not depend on the rounding
> mode, but pure calls may.

That perfectly fits with the idea of having the FP env as part of memory.

> 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 assume that an asm using this register as a constraint is already 
prevented from moving across function calls somehow? If so, at least 
gimple seems safe.

For RTL, if those asm were volatile, the default expansion would be fine. 
If they don't need to be and somehow manage to cross the pass-through asm, 
I guess a target hook to add extra input/output/clobber to the 
pass-through asm would work. Or best the target would expand the 
operations to (unspec) insns that explicitly handle exactly those 
registers.

> (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?

Yes. I'll need to look into dg-require-effective-target fenv(_exceptions) 
to see how to disable those new tests where they are not supported. There 
are many easy tests that already start working, say computing 1./3 twice 
with a change of rounding mode in between and checking that the results 
differ, or computing 1./3 and ignoring the result but checking FE_INEXACT.


On Wed, 7 Aug 2019, Joseph Myers wrote:

> On Sun, 23 Jun 2019, Marc Glisse wrote:
>
>> For constant expressions, I see a difference between
>> constexpr double third = 1. / 3.;
>> which really needs to be done at compile time, and
>> const double third = 1. / 3.;
>> which will try to evaluate the rhs as constexpr, but where the program is
>> still valid if that fails. The second one clearly should refuse to be
>> evaluated at compile time if we are specifying a dynamic rounding direction.
>
> For C, initializers with static or thread storage duration always use
> round-to-nearest and discard exceptions (see F.8.2 and F.8.5).  This is
> unaffected by FENV_ACCESS (but *is* affected by FENV_ROUND).

Thanks for the precision.

>> Note that C2x adds a pragma fenv_round that specifies a rounding direction for
>> a region of code, which seems relevant for constant expressions. That pragma
>> looks hard, but maybe some pieces would be nice to add.
>
> FENV_ROUND (and FENV_DEC_ROUND) shouldn't be that hard, given the

On the glibc side I expect it to be a lot of work, it seems to require a 
correctly rounded version of all math functions...

> optimizers avoiding code movement that doesn't respect rounding modes
> (though I'm only thinking of C here, not C++).  You'd insert appropriate
> built-in function calls to save and restore the dynamic rounding modes in
> scopes with a constant rounding mode set, taking due care about scopes
> being left through goto etc., and restore the mode around calls to
> functions that aren't meant to be affected by the constant rounding modes
> - you'd also need a built-in function to indicate to make a call that is
> affected by the constant rounding modes (and make __builtin_tgmath do that
> as well), and to define all the relevant functions as macros using that
> built-in function in the standard library headers.  Optimizations for
> architectures supporting rounding modes embedded in instructions could
> come later.
>
> Complications would include:
>
> * <float.h> constants should use hex floats to avoid being affected by the
> constant rounding mode (in turn, this may mean disallowing the FENV_ROUND
> pragma in C90 mode because of the lack of hex floats there).  If they use
> decimal rather than hex they'd need to be very long constants to have
> exactly the right value in all rounding modes.

True. I thought that was on the libc side, but no, float.h is in gcc 
indeed, and all the values are provided by the compiler as macros anyway.

I didn't look at the rounding that happens while parsing a literal yet, 
and in particular which pragmas are supposed to affect it (probably not 
fenv_access, only fenv_round).

It seems that hex floats are accepted even in C89 with a pedwarn that can 
be disabled with __extension__, although I am not sure if using 
__extension__ in __FLT_MAX__ (so it wouldn't be a pure literal anymore) 
would cause trouble.

We could also have #pragma fenv_round to_nearest (not the exact syntax) in 
float.h, although the C standard doesn't seem to have a push/pop mechanism 
to restore fenv_round at the end of the file.

> * The built-in functions to change the dynamic rounding mode can't involve
> calling fegetround / fesetround, because those are in libm and libm is not
> supposed to be required unless you call a function in <math.h>,
> <complex.h> or <fenv.h> (simply using a language feature such as a pragma
> should not introduce a libm dependency).  So a similar issue applies as
> applied with atomic compound assignment for floating-point types: every
> target with hardware floating point needs to have its own support for
> expanding those built-in functions inline, and relevant tests will FAIL
> (or be UNSUPPORTED through the compiler calling sorry () when the pragma
> is used) on targets without that support, until it is added.  (And in
> cases where the rounding modes is TLS data in libc rather than in
> hardware, such as soft-float PowerPC GNU/Linux and maybe some other cases
> for DFP, you need new implementation-namespace interfaces there to save /
> restore it.)

Honestly, that doesn't seem like a priority. Sure, long term for strict 
conformance (and a bit for performance) it could make sense, but having a 
not-strictly-legal dependency on libm when using a pragma that is meant 
for use with fenv.h seems much better than missing the functionality 
altogether.

-- 
Marc Glisse