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 [EMAIL PROTECTED] 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
