Re: Inlining and estimate_num_insns

[Richard Guenther <rguenth at tat dot physik dot uni-tuebingen dot de>]

Steven Bosscher wrote:
> 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.

Of course we are estimating "relative" sizes only.  The metric currently
is the INSNS_PER_CALL (10) number which is not dependent on the number
of arguments.  Also comparing RTL insns is in no way better than no
comparison?  If we compare with something low-level, we should compare
with text size of the object files.  Starting by building a zero-size
function size (and substracting that as a new zero) we could compare a
set of functions and check that our relative measurement is sane.  If
that works out, we could be able to provide a target-dependent 
INSNS_PER_CALL value.

Is there a convenient way to extract the text size of one function out
of a .o file?

Richard.