This is the mail archive of the
mailing list for the GCC project.
Re: Setting -frounding-math by default
On Tue, Mar 10, 2009 at 4:45 PM, Sylvain Pion
> - Show quoted text -
> 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
> having a performance cost).
> It would be nice to improve this, but a global flag, be it dedicated,
> 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
> which would reliably stop constant propagation on an expression, for
> 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
> (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
> 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 :
> ?used to allow the selection of an SSE insn for a round operation
> ?when the conditions are sufficiently relaxed (as far as I understood)
> ?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)
> ?affects definition of HONOR_SIGN_DEPENDENT_ROUNDING
> ?which is used in many places in fold-const and simplify-rtx
> ?for expression transformations.
> ?affects definition of ATTR_MATHFN_FPROUNDING
> ?which triggers const/pure attributes on "cmath" built-ins it seems.
> ?used for preventing constant folding in some cases
> ?fast-math => no-rounding-math
> ?guard ?(float)-x => -(float)x ?transformation
> ?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.
The middle-end knows about an explicit association barrier (only
used from the Fortran FE sofar), a PAREN_EXPR. Would exposing
that to C/C++ be of any help? For example it would, even with
-ffast-math, avoid constant folding for (x + FLT_EPS) - FLT_EPS
(which FLT_EPS such that proper rounding to the nearest integer
value is performed).
> - Show quoted text -
> Sylvain Pion
> INRIA Sophia-Antipolis
> Geometrica Project-Team
> CGAL, http://cgal.org/