This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Reduce inline-insns-auto
- From: Richard Guenther <richard dot guenther at gmail dot com>
- To: David Edelsohn <dje dot gcc at gmail dot com>
- Cc: Jan Hubicka <jh at suse dot cz>, Jan Hubicka <hubicka at ucw dot cz>, Mark Mitchell <mark at codesourcery dot com>, gcc-patches <gcc-patches at gcc dot gnu dot org>, Diego Novillo <dnovillo at google dot com>, Michael Matz <matz at suse dot de>
- Date: Wed, 16 Sep 2009 10:33:19 +0200
- Subject: Re: Reduce inline-insns-auto
- References: <303e1d290909151926g5afc4be4r35a6c0fc3e2ec1b3@mail.gmail.com>
On Wed, Sep 16, 2009 at 4:26 AM, David Edelsohn <dje.gcc@gmail.com> wrote:
> this patch reduces inline-insns-auto from 60 to 50. ?This does not cause
> performance regressions on our testsuite (SPEC/C++ benchmarks) and
> significandly reduces size of some C testcases from SPEC since C code
> tends to have number of functions of this size, unlike C++ benchmarks
> where majority of functions are smaller.
>
> I would like to reduce the limits further, but there is problem with eon
> benchmark where not inlining the initialization loops cause major
> regression.
>
>
> Jan,
>
> Are the units for the parameter RTL instructions? ?And you are measuring the
> effect on x86_64?
The units are sort of gimple statements and are target independent.
> If I have understood your message correctly, you have just set a
> generic parameter
> of GCC calculated in target instructions based on measurements of x86_64, a CISC
> architecture.
Which is also where the previous values of this and related parameters have
received tuning and testing.
>?You report that the eon benchmark is very sensitive to
> the result and have
> tuned the parameters for x86_64, which seems like it will push all
> RISC architectures
> over the limit.
How do you come to this conclusion?
Richard.