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
