Joseph S. Myers wrote:
On Mon, 9 Mar 2009, Sylvain Pion wrote:
Later, 1) started to be taken care of, and it was unfortunately
added under the control of the same -frounding-math option.
Which now, makes it harder to come back, since we want different
defaults for these two aspects.
I have already mentioned in a bugzilla PR that it could be nice
to have 2 options, but IIRC, I did not get any reply to this.
Patches to split the option into two *clearly-defined* options are more
likely to be accepted than changing the defaults, given that the fast-math
and related flags have been split more than once before.
My goal is to have interval arithmetic work with the default flags,
without more workarounds in the code (and as efficiently as possible).
So, I'm not going to work on anything if it means only splitting it
in separate flags, if we don't agree a priori on changing the default
for at least one of those sub flags after that.
That would be the opposite of progress for my usage, and so I would
not volunteer.
Currently, typical interval arithmetic code has to work around the fact that
there is no good way to stop constant propagation reliably (so it's using
some volatile or asm, or a big hammer like rounding-math, all these solutions
having a performance cost).
It would be nice to improve this, but a global flag, be it dedicated, strikes
me as a clearly suboptimal solution here anyway (and, as has been mentioned,
it causes problems with code which really needs cprop in other places).
For IA, having a __builtin_stop_constant_propagation(expression) would be OK,
which would reliably stop constant propagation on an expression, for example.
I don't think there's anything like that already in GCC.
That would be a real improvement, and would even improve the speed
of interval arithmetic implementations as a bonus (because it wouldn't
do any harm for the non-constant cases).
I'm not sure what you think about such a built-in : it's more general
than FP expressions, but may be only useful there in practice (?).
Maybe it might even be able to replace most concrete needs for this
aspect of -frounding-math.
Moreover, I don't know how hard it would be to implement. What do you think?
(Of course this would still not be perfect to me : the ideal compiler
interface for IA for me is something along the lines of what is described
in N2811 which attaches a compile-time rounding mode to the operations.
But at least this first step would mean progress, and might be otherwise
useful, I don't know.)
A quick audit says that the rest of -frounding-math seems indeed like it's about
expression transformations which are valid when rounding is to the nearest.
Maybe this part can indeed be seen as a subset of -fassociative-math
as Paolo mentioned, which may or may not reserve a dedicated flag.
(certainly I would push for these transformations to not be performed
by default, just like -fassociative-math)
FYI, "grep flag_rounding_math" gives the following uses of -frounding-math,
with my interpretations :
gcc/config/i386/i386.md
used to allow the selection of an SSE insn for a round operation
when the conditions are sufficiently relaxed (as far as I understood)
gcc/config/arm/arm.c
triggers an ABI related thing in the ASM files.
(I have no clue how -frounding-math could possibly
affect the ABI, but I know nothing about ARM)
gcc/flags.h
affects definition of HONOR_SIGN_DEPENDENT_ROUNDING
which is used in many places in fold-const and simplify-rtx
for expression transformations.
gcc/builtins.def
affects definition of ATTR_MATHFN_FPROUNDING
which triggers const/pure attributes on "cmath" built-ins it seems.
gcc/builtins.c
gcc/fold-const.c
used for preventing constant folding in some cases
gcc/opts.c
fast-math => no-rounding-math
gcc/convert.c
guard (float)-x => -(float)x transformation
gcc/simplify-rtx.c
guard constant folding
I have not checked all this as carefully as can be, but enough
to convince me that a good split of -frounding-math might indeed
be between (1) stopping constant propagation (where the question
is whether a builtin_stop_cprop(e) covers all needs), and
(2) "associative-math"-like transformations which could be disabled
by default.
--
Sylvain Pion
INRIA Sophia-Antipolis
Geometrica Project-Team
CGAL, http://cgal.org/
