This is the mail archive of the 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: Inlining and estimate_num_insns

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?


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