Re: Disable accumulate-outgoing-args for Generic and Buldozers

[Jakub Jelinek <jakub at redhat dot com>]

On Tue, Jan 28, 2014 at 12:56:28AM +0100, Jan Hubicka wrote:
> > On Mon, Jan 27, 2014 at 11:19:39PM +0100, Jakub Jelinek wrote:
> > > > 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.
> > 
> > Note, looking at the previous bootstraps before your change, insn-recog.o
> > was taking <= 15-16 minutes to compile both in stage2 and stage3 (the <=
> > stands for comparison of oldest *.o file in {,prev-}gcc/ directory and
> > insn-recog.o, but for the latest bootstrap stage3 I remember seeing in top
> > 58 minutes and it was still compiling, haven't looked exactly when it
> > stopped).  In any case, most likely it doesn't mean actual slow down in
> > performance of generated code, but medium slowdown in non-g compile time
> > of extreme testcase and -g compile time going wild.
> 
> I wonder if this is just some of --enable-checking tests in dwarf2out going wild
> or if it is just expensive sanity checking code?
> I used to have chroot environment for 32bit builds, I will need to re-install it now.

 variable tracking       :2914.85 (83%) usr   1.88 ( 7%) sys2931.22 (82%) wall   80844 kB ( 3%) ggc
 var-tracking dataflow   :  18.19 ( 1%) usr   0.19 ( 1%) sys  18.49 ( 1%) wall   10899 kB ( 0%) ggc
 var-tracking emit       :  29.41 ( 1%) usr   0.11 ( 0%) sys  29.65 ( 1%) wall  148128 kB ( 6%) ggc
 TOTAL                 :3525.97            25.73          3570.33            2321043 kB

So, strangely both vt_find_locations and vt_emit_notes, typically the most expensive ones,
are quite unexpensive and most of the time is spent elsewhere, in vt_initialize?

	Jakub