[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