Re: Speed up genattrtab

[Jan Hubicka <hubicka at ucw dot cz>]

> Michael Matz wrote:
> 
> > This speeds up genattrtab to be no time issue during bootstrap anymore.
> 
> > The speed difference
> > of the compiler is acceptable I think, actually even speeding up the 
> > compiler sometimes (probably cache effects, because the .text size of 
> > insn-attrtab is _much_ smaller) or being in the noise.
> 
> I certainly see how this benefits us as GCC developers.  But, it does
> look like it has a negative effect on overall compile-time, even though
> in some cases it helps a bit.  The effect seems negative, in the
> aggregate, though I didn't try to dump your table into a spreadsheet and
> actually get a number out.  I don't think we should help ourselves at
> the expense of the user's experience.
> 
> I happened to be talking to someone else this morning about this same
> issue.  Would it help just to organize the Makefile in such a way that
> this file is being built first, so that on a parallel machine it's not
> the last thing being built?  This person observed that in many cases
> make seems to wait to *start* building insn-attrtab until very late in
> the build process, meaning that all the other cores are idle while it's
> building.

In WHOPR compilation we now partition the program based on source files (this
is something I plan to revisit later), so we get partition that corresponds to
insn-attrtab.  WPA driver sorts units by size and feeds them to parallel make
and insn-attrtab is still last on finishing build by quite long shot.  This
ignore time spent by genattrtab itself.

So just reordering makefiles is not going to solve the problem.  I also think
insn-attrtab starts late because genattrtab takes long time to generate it.
insn-attrtab on i386 also has one dominating function.  With WHOPR this can
be solved by better partitioning algorithm along with function splitting (I have
prototypes of both the second I plan to contribute soon after some bugfixing).

Honza
> 
> Thanks,
> 
> -- 
> Mark Mitchell
> CodeSourcery
> mark@codesourcery.com
> (650) 331-3385 x713