Re: Inlining and estimate_num_insns

[Jan Hubicka <hubicka at ucw dot cz>]

> On Sunday 27 February 2005 14:58, Jan Hubicka wrote:
> > > >is a problem for a few people, but if you look at the performance
> > > >numbers of things like SPEC, CSiBE, and MySQL, there doesn't appear
> > > >to be any performance problem.  But your patch will probably still
> > > >blow compile time through the roof for those applications as well.
> > >
> > > I don't know.  But I also think our inlining limits are way too high,
> > > at least unnecessary high with the patch applied.  I'll try do find
> > > some more representative packages to test - any hints?  In the mean
> > > time would it be ok to apply the patch to mainline to have the automatic
> > > testers do some tests and then afterwards maybe revert it, if we do
> > > not like it?  I'll take the previous approval of Jan as taken back
> > > for now.
> >
> > Well, I still think that the metric without artificial assignemnts is
> > more realistic
> 
> And you know this how?  When I last toyed with this, I compared the
> actual number of RTL insns generated for a function with the estimate
> we made.  I have not seen a comparison of that so far.  Maybe we are
> now way underestimating the sizes.

Yeah, comparsion to real numbers of insns is one of things we should
consider.  However we need to take into acount also the fact that some
constructs optimize better when inlined than others.  Wast majority of
copy instructions is elliminated (I generated some numbers on this for
tree-profiling branch but they are right now sitting on my dead
hardrive), so Richard's idea looks sensible.
Basically we need to explain inliner that the abstraction functions are
free to get sane results on C++...
> 
> 
> > so the path of using your patch in combination of 
> > re-benchmarking the inlining limits is proper way to go.
> 
> In principle, yes.  But we really need to investigate more carefully
> than this.  Especially if this is intended for 4.0 (and IMHO it is
Definitly.
> too late for that).

I would say that simple changes in metrics would be OK assuming that
they help the testcases with high abstraction (naturally at compilation
time cost but not code size cost) and don't slow down testcases with low
abstractions, but I am not developer of highly abstracted code definitly
so C++ folks needs to speak here.  Lets give this a try and see how far
we can get.

Anything more involved would have to wait for 4.1 I think.
> 
> > I would not 
> > expect drastic slowdown in testcases that don't suffer from abstraction
> > penalty.  I will test it on SPEC tonight and send you a results
> > tomorrow so lets see how intuition works here.
> 
> Maybe you could test DLV and Gerald's other C++ benchmarks as well.

Sure, this is what I intend to do shortly.
> 
> > The basic idea is that we need to recognize "forwarder" functions as
> > being free to get sane performance on funny C++ template codes.  I was
> > even thinking about some kind of pattern matching for common cases (ie
> > functions just passing their arguments to other functions and similar)
> > and forcing their costs to be CALL_INSN_COST, but didn't get across that
> > yet.
> 
> Another idea might be to give "small" functions with one or more
> constant arguments a smaller inlining penalty.

We can increase CALL_INSN_COST to be function of number of arguments and
subtract some cost for constant arguments (but this is where IPACP and
function clonning should find the fruits).  I've experimented with this
in 3.4 times and didn't get any consistent results (ie there were hits
or misses), but it might be interesting to re-try since things has
changed since than.
> 
> 
> > So we should slow down compilation of testcases like tramp3d to 
> > get sane performance and not affect too much lower level code, like
> > SPEC.
> 
> Or have different inlining heuristics for C++.

I tend to thing that common heuristics smart enought to catch C++
abstraction should do fine for both.  Inlining is hitting us before each
release, now imagine twice as many arugments here!

The only problem with common heuristics I see is that in C the "inline"
keyword is very strong hint basically meaning "I use language extension
because I really want to inline it", while in C++ it is "maybe I want to
inline it, but maybe I just put it to header for fun".  We might want to
distinguish these in the case we fail to deal with them in common
miserably.

Honza
> 
> Gr.
> Steven