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