This is the mail archive of the
mailing list for the GCC project.
Re: splitting insn-attrtab.c? (was: [patch] Tighten pre-requisites for parallel make)
- From: Laurent GUERBY <laurent at guerby dot net>
- To: Paolo Bonzini <bonzini at gnu dot org>
- Cc: Ralf Wildenhues <Ralf dot Wildenhues at gmx dot de>, Michael Matz <matz at suse dot de>, gcc-patches at gcc dot gnu dot org, Richard Guenther <richard dot guenther at gmail dot com>
- Date: Mon, 20 Apr 2009 11:56:25 +0200
- Subject: Re: splitting insn-attrtab.c? (was: [patch] Tighten pre-requisites for parallel make)
- References: <Pine.LNX.firstname.lastname@example.org> <20090420055746.GC30096@gmx.de> <49EC269B.email@example.com>
On Mon, 2009-04-20 at 09:39 +0200, Paolo Bonzini wrote:
> Ralf Wildenhues wrote:
> > Hello Michael,
> > * Michael Matz wrote on Mon, Apr 20, 2009 at 04:14:31AM CEST:
> >> we use order-only pre-requisites of GNU make to make sure that the
> >> generated files are generated very early.
> > Yes, but we also used it to direct 'make' to compile insn-attrtab as
> > soon as possible. It may well be that we didn't try this change that
> > you have now, or some other circumstance didn't let this seem beneficial
> > then. Which make version did you test with?
> insn-attrtab is compiled as soon as possible anyway because it's at the
> top of OBJS-common.
On the compile farm at make -j 8 on a x86_64 bi-quad each stage
insn-attrtab.c compilation finishes alone. I did some measurement on
gcc16 with the flags from bootstrap log (-g -O2 & others):
Last stage compilation of insn-attrtab.c, best of 5 runs:
I manually splitted the file by putting the 70 klines
internal_dfa_insn_code function plus a copy of include list in a
separate file x1.c, the rest left in x0.c, results:
Compiling x0.c, best of 5 runs:
Compiling x1.c, best of 5 runs:
Total best: 3m01s
I measured compiling the includes plus just insn_current_length, a small
function, at 0.4s so for the best time it seems coherent as overhead.
I observed significant variance in my measurement even if the machine
was not loaded, sometimes up to +30 seconds for a given compile,
I have no explanation for this variance. Memory used goes up to 330MB.
For reference, compiling insn-attrtab.c at -O0 (instead of -O2) is about
29 seconds, at -O1: 1mn32s.
So for x86_64 splitting this generated file in two following what I did
manually would lead to a very modest slowdown in the -j 1 case
(about two seconds if measurable) and in theory for -j N with N >=2
about 3 minutes ouf of 24 minutes at -j 8 on gcc16.
On other platforms I don't know if insn-attrtab.c is showing on the
Thanks in advance,