This is the mail archive of the gcc@gcc.gnu.org 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: [PATCH] gcc-3.3: Make -finline-limit work (PR/8387)


Kurt Garloff <garloff at suse dot de> writes:

> 1. In gcc-3_3-branch, the first patch (as attached in the mail from
>    saturday) should IMHO be applied as it fixes PR/8387. Before 3.3.0
>    release if it's further delayed, otherwise afterwards.
>    Note that we've seen a kernel compile failure on x86-64 with 3.3
>    snapshots which was due to a a function not being inlined because
>    it was considered too large and the increased -finline-limit passed by 
>    the Makefile was not effective.
>    So if kernel compilation is a release criterium for 3.3, the fix 
>    should go in in any case.

The 3.3 release can't happen right now, because (among other things)
there's a codegen regression on Darwin.  This patch is reasonably safe
and fairly important (especially if it affects linux kernel
compilation), so I think it should go in; Dale volunteered to do the
actual commit.

...
>   So, probably, we want to have a lower initialization for the 
>   max-inline-insns-auto parameter (val*2/5 or val/3) but use a slightly
>   increased default value for -finline-limit, like e.g. 720 with /3,
>   resulting in 720,360,240,130. Or 700 with 2/5, giving 700,350,280,130.
>   My benchmarks suggest numbers in this region.
> 
>   But probably others also want to check what their benchmarks tell.

Sure.  It may help if you propose a patch, that way people can more
easily run their own tests.

-- 
- Geoffrey Keating <geoffk at geoffk dot org>


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