This is the mail archive of the gcc@gcc.gnu.org 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: Please try out new inlining heuristics


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


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


> 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 :-)


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


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

Gr.
Steven


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