RFC Exploratory Patch - Significant performance improvement

[Jerry DeLisle]

On 12/11/2009 12:36 AM, Paul Richard Thomas wrote:
> Hi Jerry,
>
>>> "Significant" is quite an understatement!-) Spectacular would fit.
>
> Indeed!
>
> I was curious about one chunk, after your previous patch that fixed a
> problem due to the side effects of gfc_is_constant_expr.  Doesn't
> gfc_is_constant_expr actually expand the constructor, so that the
> gfc_expand_constructor is redundant?
>
> @@ -5549,7 +5573,8 @@ gfc_resolve_expr (gfc_expr *e)
>         if (t == SUCCESS)
>   	{
>   	  expression_rank (e);
> -	  gfc_expand_constructor (e);
> +	  if (gfc_is_constant_expr (e) || gfc_is_expandable_expr (e))
> +	    gfc_expand_constructor (e);
>   	}
>
>         /* This provides the opportunity for the length of constructors with
>
> I must say that it concerns me more and more that gfc_is_constant_expr
> has the effect of expanding constructors; not only because of the side
> effect that we saw previously but also because it slows up the
> compiler by forcing repeated traverses of the expanded expression,
> rather than leaving the expansion to the last moment.
>
> What do you think?
>
I understand your concern.  With the patch for 20923, the number of expansions 
is reduced.  In many cases gfc_is_constant_expr does no expansion.  Without the 
gfc_is_constant_expr in the above hunk, we get several regressions on the 
array_constructor_X tests.

I still think there may be something fundamental lurking in here in the sense of 
how we have the code factored.  There are numerous working functions to choose 
from that are used by expand_constructor.  Some of those do not actually expand 
anything.  They simply traverse or walk the constructor.

So it may be possible, by further exploration, to consolidate all this and do 
the "expansion" one time.  There are three or four places where 
gfc_expand_constructor, the top level function, is called.  Some of these are at 
the parsing/matching phase, others at resolution phase.

Jerry