This is the mail archive of the
mailing list for the GCC project.
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
Well, I still think that the metric without artificial assignemnts is
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
Is there a convenient way to extract the text size of one function out
of a .o file?