> 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.
Honza
>
> Jakub
