This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Disable accumulate-outgoing-args for Generic and Buldozers
- From: Jakub Jelinek <jakub at redhat dot com>
- To: Jan Hubicka <hubicka at ucw dot cz>, Alexandre Oliva <aoliva at redhat dot com>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Mon, 27 Jan 2014 23:19:39 +0100
- Subject: Re: Disable accumulate-outgoing-args for Generic and Buldozers
- Authentication-results: sourceware.org; auth=none
- References: <20140101143004 dot GD26209 at kam dot mff dot cuni dot cz> <20140124211119 dot GX892 at tucnak dot redhat dot com>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
On Fri, Jan 24, 2014 at 10:11:20PM +0100, Jakub Jelinek wrote:
> On Wed, Jan 01, 2014 at 03:30:04PM +0100, Jan Hubicka wrote:
> > * config/i38/x86-tune.def: Disable X86_TUNE_ACCUMULATE_OUTGOING_ARGS
> > for generic and recent AMD chips
> > Index: config/i386/x86-tune.def
> > ===================================================================
> > --- config/i386/x86-tune.def (revision 206233)
> > +++ config/i386/x86-tune.def (working copy)
> > @@ -143,7 +143,7 @@ DEF_TUNE (X86_TUNE_REASSOC_FP_TO_PARALLE
> > regression on mgrid due to IRA limitation leading to unecessary
> > use of the frame pointer in 32bit mode. */
> > DEF_TUNE (X86_TUNE_ACCUMULATE_OUTGOING_ARGS, "accumulate_outgoing_args",
> > - m_PPRO | m_P4_NOCONA | m_BONNELL | m_SILVERMONT | m_AMD_MULTIPLE | m_GENERIC)
> > + m_PPRO | m_P4_NOCONA | m_BONNELL | m_SILVERMONT | m_ATHLON_K8)
> >
> > /* X86_TUNE_PROLOGUE_USING_MOVE: Do not use push/pop in prologues that are
> > considered on critical path. */
>
> Are you sure this is a good idea even for 32-bit code (i.e. shouldn't we
> have separate tunables for 32-bit and 64-bit code)?
> I admit I haven't performed trunk bootstraps/regtests for 3 days, am doing
> x86_64 and i686 bootstraps/regtests concurrently and it is yes,rtl checking,
> but am quite surprised that compared to 3 days ago the bootstrap time of
> i686-linux (all,obj-c++,go) went up from about 70 minutes or so to 140 minutes today,
> while the x86_64-linux (all,obj-c++,go,ada) remained basically the same
> around 2 hours. This is on quad socket Quad-Core AMD Opteron(tm) Processor 8354,
> perhaps it is just extremely undesirable there.
Most likely the big slowdown is var-tracking, at least stage2 insn-recog.o
(yes,rtl checking on i686-linux) took <= 23 minutes to compile and stage3
<= 62 minutes, with 45 minutes from that only spent on compiling
insn-recog.o and nothing else.
Jakub