This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Threading the compiler
- From: Michael Eager <eager at eagercon dot com>
- To: Mike Stump <mrs at apple dot com>
- Cc: GCC Development <gcc at gcc dot gnu dot org>
- Date: Sat, 11 Nov 2006 11:42:52 -0800
- Subject: Re: Threading the compiler
- References: <D5E71E91-8A8D-4472-95DD-8C03C1E218C8@apple.com>
Mike Stump wrote:
Thoughts?
Parallelizing GCC is an interesting problem for a couple
reasons: First, the problem is inherently sequential.
Second, GCC expects that each step in the process happens
in order, one after the other.
Most invocations of GCC are part of a "cluster" of similar
invocations. If we look at this cluster, rather than at
individual invocations, there may be opportunities for
parallelization. Make -j allows several commands to run at
the same time. It may be reasonable to incorporate some
of the same functionality in the GCC driver, so that it
starts processing threads in the background and exits. (There
is the interesting question of how threads are re-synced.)
Parsing the source is inherently a sequential operation.
I don't think that it is possible to parse different include
files independently in separate threads, or even identify the
dependencies between include files. But it may be possible
to use the results of parsing an include file (or sequence of
include files) from another instance of GCC which is executing
in a different process or thread.
Each of the functions in a C/C++ program is dependent on
the global environment, but each is independent of each other.
Separate threads could process the tree/RTL for each function
independently, with the results merged on completion. This
may interact adversely with some global optimizations, such
as inlining.
--
Michael Eager eager@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077