This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Whole program optimization and functions-only-called-once.
- From: Richard Guenther <richard dot guenther at gmail dot com>
- To: Jan Hubicka <hubicka at ucw dot cz>
- Cc: Toon Moene <toon at moene dot org>, Jan Hubicka <jh at suse dot cz>, gcc-patches at gcc dot gnu dot org
- Date: Mon, 16 Nov 2009 08:23:53 -0600
- Subject: Re: Whole program optimization and functions-only-called-once.
- References: <4AF1D3C2.3000001@moene.org> <84fc9c000911041126x14ce9226w9dfb781ea284de6b@mail.gmail.com> <20091112161638.GC11341@atrey.karlin.mff.cuni.cz> <4AFEA884.9030003@moene.org> <20091116095435.GU24874@kam.mff.cuni.cz>
On Mon, Nov 16, 2009 at 3:54 AM, Jan Hubicka <hubicka@ucw.cz> wrote:
>> Jan Hubicka wrote:
>>
>>> -fno-ipa-cp should work around your problem for time being.
>>
>> Indeed it did. Some figures:
>
> Thanks for confirmation!
>
>> Considering invlo4 size 1462.
>> ?Called once from lowpass 2293 insns.
>> ?Not inlined because --param large-function-growth limit reached.
>>
>> Considering invlo2 size 933.
>> ?Called once from lowpass 2293 insns.
>> ?Not inlined because --param large-function-growth limit reached.
>>
>> where the largest callee *does* get inlined, while two smaller ones
>> don't (I agree with Jan that this would have been solved by training the
>> inliner with profiling data, because only invlo4 gets called).
>
> Using profiling data does not really make inliner to bypass
> large-function-growth. ?We can experiment with large-function-growth tweaking.
> So far i didn't see any testcase where this limit would result in runtime
> regression.
I think we shouldn't bypass large-function-growth. We might want to scale
it somewhat for hot callgraph edges (and at the same time avoid inlining
once-called cold functions). Or even better sort the fibheap according to
the callgraph edge frequency, not only according to sizes.
Richard.