Re: inliner in gcc-3.1

[Kurt Garloff <garloff@suse.de>]

[-- Attachment #1: Type: text/plain, Size: 3139 bytes --]

Hi Gerald,

thanks for testing!

On Thu, Apr 25, 2002 at 06:36:10PM +0200, Gerald Pfeifer wrote:
> On Wed, 24 Apr 2002, Kurt Garloff wrote:
> > It would be nice if this patch
> > http://www.garloff.de/kurt/freesoft/gcc/gcc310-inline-func-acct-v1.diff
> > would be tested by more people and integrated into 3.1.
> 
> This second patch (partially) fixes a very bad regression we've been
> having since GCC 3.0; build time and binary size seem to be fine, though
> we seem to degrade slightly for some of the other benchmarks.
> 
> I'd really like to see what this does to SPEC -- Andreas, could you give
> it a try?

Actually, maybe we should wait a second.

When I developed the patch on 3.0.1, I was not seeing the degradation you
see now for some benchmarks. So I must have done some mistake when porting
it from 3.0.1 to 3.1, or some assumption I made is not true any more.
I've done some more benchmarks with this inline accounting patch and
I also have found a case with performance regression against v3, even
without -finline-functions, so something must have gone wrong I think.

What I try to do in the patch is to improve -O3 (-finline-functions)
performance. The idea is to keep the information whether a function was
declared inline or whether it got inlined by virtue of the automatic
inlining. I may have screwed this up ... and set the flag when it
should not, so we actually treat the inline declared function with the 
lower automatic limit.
(a) The declared inline fn would get the full 300/600 limit whereas the
    automatically inlined ones only half. [The idea is that we still think
    the programmer has a bit of a clue. Maybe the factor 0.5 is a bit too
    strict.]

The patch also does two other things that have proven useful on 2.95.3
(b) better tune -Os (again tested on i386)
(c) give leaf functions a bonus (*3/2) in the RTL inliner
    [is it still used at all?]

Maybe one should separate those issues and verify that do what my intention
was.

I would certainly appreciate if somebody with some more knowledge of the
compiler internals would have a look.
Any takers?

> (This is due to a C module in the C++ application, and your fix seems
> to be critical for many C applications in general.)
> 
>                      build time   binary size
>   2.95.3                   4:01   4430752
>   3.0                     23:54   6295044
>   3.0.3                    3:58   3948444
>   3.1-20020422             4:38   3996096  <-- without patch
>   3.1-20020424+kurt-v3     5:35   4102432
>   3.1.20020425+kurt-finl.  4:32   3912640  <-- this is with the patch

This is with both patches I assume.

I'm astonished we beat plain 0422 at build time and binary size.

But the benchmark results do not really look attractive to me. We only 
win one benchmark against -v3, and even against plain we sometimes lose.

Regards,
-- 
Kurt Garloff  <garloff@suse.de>                          Eindhoven, NL
GPG key: See mail header, key servers         Linux kernel development
SuSE Linux AG, Nuernberg, DE                            SCSI, Security

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]