Re: Inlining and estimate_num_insns

[Steven Bosscher <stevenb at suse dot de>]

On Monday 28 February 2005 01:46, Giovanni Bajo wrote:
> Richard showed already how his patches help on some of the benchamarks you
> suggested. They also fix a regression since 3.4 was so much better in this
> regard.

And it may introduce new ones.

> Of course, compilation time goes up somehow because we are doing 
> more work now,

Your definition of "somewhat" is really off.  From Richard's mail
(http://gcc.gnu.org/ml/gcc/2005-02/msg01073.html):

PR8361 -O3 compile times are
 
 3.4          25s
 4.0          20s
 4.0 patched  31s

Now, let me see... Hmm... 11s slowdown on 20s, that is more than 50%.
If that is "somewhat" and "a few percent" for you, then I don't want
to know what you consider to be a serious compile time slowdown ;-)

> but the compile time *regression* is probably because of 
> something else and is merely uncovered by Richard's patches.

Probably, but we don't know that, now do we?  So we need to figure
that out first, instead of being all emotional over this.

If you look at the graph Richard made (find it here:
http://gcc.gnu.org/ml/gcc-patches/2005-02/msg01608.html), and at the
measurements he presented in another mail, it's obvious that the new
heuristics he proposes give *smaller* estimates than 3.4.  Part of
the slowdown may be in there as well.  And maybe the inline limits
are too *high* after Richard's patch.

The patch needs to go though a whole new process of tuning, and that
takes time.  This patch could be very destabilizing for GCC 4.0, so
we *have* to be careful, and know what effects the patch will have on
normal code (ie. not the heavily templatized C++ that you seem to love
and I definitely hate so much).

If you have a problem with that, and this is such a big deal for you,
maybe you should ask yourself "Why did I not complain about this
problem long ago, months before branching GCC4".  Because you work on
and with GCC a lot, and I haven't heard you complain about this before.

> I'm not sure we should hold such a patch to save a few percent of
> compilation time at -O3.

Explain that to the many users who have complained about compile time
problems in the past.  Like Karel Gardas for example.  I don't recall
him saying he had performance problems with GCC 4.0, but he definitely
had some problems with compile time issues.  And there are many like
him.

> -O3 (compared to -O2) means "try to inline 
> harder". Richard's patches are doing exactly that. I'm sure who uses -O3
> doesn't mind us doing better what we are asked for. And if compilation time
> is critical for them, they can still use -O2.

These heuristics affect -O2 compile times just as well.

> Also, I would like to see detailed reports of where the compilation time
> goes, after the patch.

That would be nice yes.  But...

> I'm sure we can go blaming other optimizers 
> (probably some of the new ones) for the compile time regression.

...it is unlikely that putting the blame somewhere will magically make 
those perceived problems go away.

I can only wonder why we are having this discussion just after GCC 4.0
was branched, while it was obvious already two years ago that inlining
heuristics were going to be a difficult item with tree-ssa.

Gr.
Steven