Re: Please try out new inlining heuristics

[Jan Hubicka <jh at suse dot cz>]

> > > So you try tuning your new inliner heuristics with very broken
> > > function body size heuristics.  When somebody later fixes the 
> > > latter, you can start all over again.
> >
> > Yes, kind of.
> > My belief is that the code size estimate is quite entirely broken, but
> > fixing it properly needs lower level language (like we do have on AST
> > branch), so I don't want to get too far into busyness of trying to
> > develop some wrong sollution to this.  I realize I am doing this with
> 
> Probably.  Maybe we can add a langhook for 3.4 and make function size
> estimates language-specific.  For 3.5 with the AST this would go away again
> and we'd write something better to estimate the size of a function in GIMPLE
> form.

Perhaps.  I hope to do this independently on the reorganization of
inlining heuristics itself tought.  Given that we have better estimates,
it should just work better.
> 
> 
> > inlinining heuristics itself, but I am primarily interested in the
> > interfaces to be set up and whant to get the heuristics itself very
> > trivial, if possible, and extend it once AST is on place.
> 
> IMHO the trivial inline heuristics only work if the function body size
> estimate is sensible.

Yes, however with cgraph we can derive some information from the
callgraph itself being less dependent on the estimates.  I am just
experimenting with this.
> > But perhaps simple code in add_stmt to skip statements that are actually
> > nops (like scope regions) would do a wonders.  From where the mistake
> 
> Yup, that is something we could try. We should not forget to update
> MIN_INLINE_INSNS, which is exactly the size of a function with a single
> statement :-)

This sounds sane, I will try to play with this.
> > comes?  (ie is it actually the case that final function body has 20
> > statements, or are the statements constructed but lost later by
> > instantiation or so?  Perhaps simple walk of function counting real
> > statements in function body would do better job.
> 
> I am not entirely sure.  But from what I recall from last time I looked at
> it, G++ first counts statements when building the template, and then counts
> them again during instantiation.  Adding a single statement would add more
> than one statement in DECL_NUM_STMTS.  I'll have a look today and see if I
> can give you a few more details and some kind of test case.
> 
> A tree walk may indeed do better, but we would have to deal
> language-specific tree nodes (hence my suggestion for a langhook).

Please try to look closer.  This would explain why C++ is pushing the
limits up now.
> 
> 
> > Would be possible for you to construct simple testcase where I can see
> > the problem?
> 
> PR1687 is one you can look at so see how a huge expression in an "if"
> statement counts as a single statement but expands to several 100 insns.

Yes, however this is something I probably don't want to get into before
gimple :(

Honza
> 
> Gr.
> Steven