This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Improve unrolled size estimates

On Mon, 11 May 2009, Jan Hubicka wrote:

> > 
> > You visit SSA_NAMEs multiple times if they are used as array index.
> Yes, chaching is easy.
> > 
> > > The problem I run into here was that with my fix to estimate_num_insns
> > > those loads/stores are no longer estimated to cost of 0 (they are not
> > > :).  In this we prevent unrolling of loop body then.  I can also simply
> > > ignore the testcases and add PR as discussed earlier.
> > 
> > Well, doing such a fixup only for existing testcases sounds bad.  There
> > is certainly code around with different kind of constant initializers.
> > 
> > We have fold_const_aggregate_ref () in tree-ssa-ccp.c that is more
> > generic, but you would need to either build a new tree with constant
> > replacements (would simply using zero always do?) or temporarily
> > patch/unpatch the existing tree.
> Just for record here, the testcase that originally motivated me to add
> the code is loop-37.c.  It has two loop of style:
> 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)

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]