On Tue, Mar 10, 2009 at 4:45 PM, Sylvain Pion <sylvain.p...@sophia.inria.fr> wrote: > - 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 > 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.
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). Richard. > - Show quoted text - > > -- > Sylvain Pion > INRIA Sophia-Antipolis > Geometrica Project-Team > CGAL, http://cgal.org/ >
