This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Improve unrolled size estimates
On Mon, 11 May 2009, Jan Hubicka wrote:
> > > 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)
Yes, that's a missed optimization. We'd need to invent some tree
to return for 'unknown constant' though.
Richard.