[Patch, Fortran, RFC] Improve common function elimination

[Thomas Koenig]

Hi Janne,

> 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?

And so it does... ouch.  This makes me move a bit more into the
--fast-math hater's camp.  Steve, is there a

>> 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?

Not in all cases.  With the macro approach, I was trying to make as
few changes as possible to already complicated code to minimize the
chance of regressions.  The code in gfc_dep_compare_expr has so many
return statements that I felt this the safest route.

(After switching on the return poisoning, I found that I only had
forgotten two statements :-)

> 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?

Maybe not.  I haven't thought this through all the way for this concept
patch; I was just trying to be cautious here.

>
> Furthermore, couldn't the same optimization be applied to complex as
> well?

Of course. The change required would actually be quite small.

> Finally, why can't the middle-end already do this kind of
> optimization, as long as we mark functions as pure/const or whatever?

First, the middle-end cannot handle vector-valued functions.

Also, the middle-end uses SSA, so information on what originally was
in a single expression is lost.  This is important because pure
functions can depend on module or common variables; they just
cannot set them.  If the middle-end finds a pure function with
some SSA statements in between, it gets much harder to optimize.

Maybe we need a snow_white_pure attribute to denote functions which
also don't depend on external state :-)

	Thomas