This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH] gcc-3.3: Make -finline-limit work (PR/8387)
- From: Geoff Keating <geoffk at geoffk dot org>
- To: Kurt Garloff <garloff at suse dot de>
- Cc: gcc at gcc dot gnu dot org, dalej at apple dot com
- Date: 05 Mar 2003 13:45:55 -0800
- Subject: Re: [PATCH] gcc-3.3: Make -finline-limit work (PR/8387)
- References: <20030302160629.GV16943@nbkurt> <email@example.com><20030304012745.GH3017@nbkurt> <20030305192315.GO11208@E2.suse.de>
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
> 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>