Re: [tree-ssa] Preliminary analysis on POOMA slow downs (was Re:[tree-ssa] Speed up constant propagation)

[Steven Bosscher <s dot bosscher at student dot tudelft dot nl>]

Daniel Berlin wrote:

> On Tue, 17 Jun 2003, Steven Bosscher wrote:
>
> > Daniel Berlin wrote:
> >
> > > On Tuesday, June 17, 2003, at 01:07  PM, Diego Novillo wrote:
> > >
> > >
> > > > I'm a bit surprised that the inliner is taking such a big hit.
> > >
> > >
> > > Hrmmmmm.
> > > Remember we downed INSNS_PER_STMT (tree-inline.c), which increases the
> > > amount of inlining done.
> > > That was done only considering the effects of GIMPLE on C (and even
> > > then, it was a while ago).
> > > It might need reevaluation in light of C++ gimplification, etc.
> > AFAICT it was never done and INSNS_PER_STMT is 10 on both mainline and
> > branch.
> So yer right.
> Whoops.
> I never committed it.
> :)

Actually I've been wondering if it makes a difference if you change it 
or not.  The problem is not so much in INSNS_PER_STMT, but more in how 
we estimate the size of function trees.

The size of the function is estimated with 
DECL_NUM_STMTS*INSNS_PER_STMT, and DECL_NUM_STMTS is only set by the 
front end.  FWIW that is also why we do so poorly on C++ inlining, so it 
should be replaced with a less inaccurate estimate.  We currently 
overestimate the number if insns for most functions, so the current 
MAX_INSNS_* params are too large.  But on tree-ssa

I had the idea to set INSNS_PER_STMT to 3 and multiplying that by the 
number of nodes for which IS_EXPR_CODE_CLASS is true in the gimplified 
function tree (finding them with a tree walk), but that was too 
expensive for some tests I did (PR 8361, etc).

> > It looks more like you suffer from the extra pointers from the tree
> > iterators and from the extra tree copying because GIMPLE has more trees
> > and unshares everything.
> Don't start the sharing argument again.

Oh sorry, I didn't even know there was an argument about it, so I 
wouldn't even know what to argue about :-)

BTW Diego, you may wish to try my patch for PR 1687 
(http://gcc.gnu.org/ml/gcc-patches/2003-05/msg00179.html) which went 
into 3.3 but not (yet) to mainline.  I don't know if it helps, but it 
may be worth a try.

Gr.
Steven