Re: Improve unrolled size estimates

[Jan Hubicka <hubicka at ucw dot cz>]

> > static const int my_array [3] = { 4, 5, 6 };
> > 
> > void f0 (void)
> > {
> >   int j, sum = 0;
> >   for (j = 0; j < 3; j ++)
> >     sum += my_array [j];
> > 
> > And later tests that all references to my_array goes away.
> > 
> > This is quite silly testcase, so I think we can just add -O3 into it
> > that will make cunrolli to unroll even when increasing size and be
> > happy.
> 
> Well, it is as silly as testcases that reference constant strings ...
> (read: not silly)

Well, it is silly in a way that it insist that all traces of the
original array are eliminated after unrolling. This happens when loop is
unrolled in cunrolli.  Even with the normal metrics, cunroll unrolls the
loop, it is just cunrolli that misses the transform.  We don't run CCP
after complette_unroll so we don't fold accesses to constants
afterwards.
> 
> > I don't think fold_const_aggregate_ref fits my need here: I don't know
> > the particular constant offset (it is different in every iteration), I
> > only want to check that we are going to get constant offset into array
> > that has initializer known, so fold_const_aggregate_ref will match then.
> 
> Well, you can test if it matches by feeding it random constant.  Of
> course fold_const_aggregate_ref uses CCP lattice - which you could
> use to cache your simple_iv results, so it doesn't even need ref
> tree patching.

I guess it ought to handle unknown constant too and claim that result is
unknown constant, right? (it doesn't)

Honza
> 
> > I run simple statistics on testsuite how often this match, the most
> > common case is the STRING_CST case: i.e. loops that do something on the
> > constant strings, like hand coded strcpy from constant string to new
> > location or so.
> 
> I can certainly imagine that disregarding loads from constant initializers
> is important.  Thus I agree to keep that optimization, but please use
> existing generic helpers.
> 
> Richard.