If you had a month to improve gcc build parallelization, where would you begin?

[Jeff Law]

On 04/03/2013 09:27 AM, Simon Baldwin wrote:
> Suppose you had a month in which to reorganise gcc so that it builds
> its 3-stage bootstrap and runtime libraries in some massively parallel
> fashion, without hardware or resource constraints(*).  How might you
> approach this?
>
> I'm looking for ideas on improving the build time of gcc itself.  So
> far I have identified two problem areas:
One of the things I've noticed is multilib library targets don't build 
in parallel.

I noticed this mostly in libjava, but it applies to others that use the 
automake generated bits.  Basically the i686 version of the library 
won't start building until the x86_64 version has completed due to 
Makefile lameness.


>
> - Structural.  In a 3-stage bootstrap, each stage depends on the
> output of the one before.  No matter what does the actual compilation
> (make, jam, and so on), this constrains the options.
> - Mechanical.  Configure scripts cause bottlenecks in the build
> process.  Even if compilation is offloaded onto something like distcc,
> configures run locally and randomly throughout the complete build,
> rather than (say) all at once upfront.  Source code compilation
> blocks until configure is completed.
>
> One way to improve the first might be to build the runtime libraries
> with stage2 and interleave with stage3 build on the assumption that
> comparison will pass.  That probably won't produce an exciting
> speedup, likely modest at best.
Well, you could (for example) start building libraries as soon as the 
appropriate front-end bits are in place.  So for example, if we have a 
library that is just C code, it can start building as soon as the C 
front-end has been build.  C++ bits start as soon as the C++ front-end 
is built, etc.  You could possibly get fine grained control and 
partially build libraries which use multiple languages.

That'd be a huge structural overhaul as well.


In my experience, running the testsuite takes longer than the build.  So 
you could fire up the testsuite as soon as stage2 is built so that the 
testsuite and stage3 are running together.

Sharing configury caches was a significant help in the huge single 
source trees that Cygnus used to use (gcc, binutils, gdb, flex, bison, 
sim, tcl, tk, expect, make, etc etc all in one source tree sharing 
config.cache).  Might be able to do that again and possibly do it on the 
target library side as well.

There may be other ideas floating out there.


jeff