[Patch, Fortran, RFC] Improve common function elimination
Janne Blomqvist
blomqvist.janne@gmail.com
Mon Dec 12 09:40:00 GMT 2011
On Mon, Dec 12, 2011 at 02:44, Thomas Koenig <tkoenig@netcologne.de> wrote:
> Maybe this patch also fixes previous bugs where we would
> assume that a < a + 1. with --fast-math.
Isn't the point with -ffast-math exactly that we are allowed to
optimize such expressions?
> What is the general feeling about this approach?
Overall I think the idea is sound. In particular, comparing for
equality only should avoid most of the usual FP pitfalls. However, I
don't like the macro magic in the patch itself; does every return from
the function really need to check whether the type is REAL or not?
Also, from the patch:
+ if (e1->ts.type == BT_REAL && e2->ts.type == BT_REAL)
+ {
+ if (e1->ts.kind != e2->ts.kind)
+ RETURN (-2);
+
+ if (mpfr_cmp (e1->value.real, e2->value.real) == 0)
+ RETURN (0);
+ else
+ RETURN (-2);
+ }
Is the kind check actually necessary? If the value happens to be
exactly representable in both kinds, why not say they are equal? E.g.
2.0 == 2.0d0, right? And if they aren't mpfr_cmp should catch it, no?
One problem, I suppose, is if this comparison is done before generic
resolution (e.g. cos(2.0) != cos(2.0d0))?
Furthermore, couldn't the same optimization be applied to complex as
well? I'm not saying you need to worry about that right now, but that
could be a further patch, if this one is deemed acceptable?
Finally, why can't the middle-end already do this kind of
optimization, as long as we mark functions as pure/const or whatever?
--
Janne Blomqvist
More information about the Fortran
mailing list