Problems in GCC

-- data-struc transform thing -- does transforms for multi-core..  but will want to do them differently for 100 core with directory based coherence rather than 8 core..  and differently again for a 4 socket by 8 core machine

-- but it's embedded inside GCC!  Working on it is prohibitive, given the GCC internals. 

Worse, making a new version of this transform, which is naturally a source-to-source transform, for every new hardware configuration, times all the other source-to-source transforms being embedded into GCC (counted 5 at HiPEAC alone)..  makes GCC a behemoth!   Dozens of versions of hundreds of source-to-source transforms, each with their own command-line parameters is a nightmare.

Worse again, getting such a tool into the main-line is prohibitive.  Not only does getting approval require significant effort from the developer, but it wastes the time of the GCC board.

The effect is to prevent much of this research from being done, and prevents what is done from becoming available, in practice, to the community.

Worse yet, the GCC manual is currently at 1200 pages!  This is about to explode, given all the source-to-source transforms for parallelism that groups want to put into GCC..  another nightmare.

And just think about the explosion of the build process.

Worse again, these tools lose performance because they have no control over which other passes are performed and in what order.

HELP!

None of these source-to-source transforms aimed at parallelism fundamentally need to be inside GCC..  they require the various analyses that other GCC passes perform, and often want to start at the output produced by a specific preceeding pass..  but this can be provided by extracting the source-to-source passes, leaving only the core passes that have tight coupling, and making the core a Dynamic Link Library.