[LLVMdev] parallelizing llvm

[Chris Lattner]

On Thu, 3 Jul 2008, Eli Friedman wrote:
>> Does this mean llvm can not dominate if llvm target 1 core machine
>> also ?
>
> Making an optimizer/code generator parallel is fundamentally a lot
> easier than making a browser parallel because the problems parallelize
> a lot more naturally.  There are essentially two chunks of code in the
> llvm pipeline that take up large amounts of time: the optimization
> passes and the code generator.  I think parallelizing both of these is
> feasible with conventional parallelism techniques, with very little
> penalty for the single-core case.

This is also something I'm interested in supporting.  The whole design of 
the FunctionPassManager and CallGraphSCCPassManager (e.g. inliner) is to 
allow parallelism of optimizations between different parts of the program.

There are three main problems with this:

1) There are various places in LLVM that use globals, e.g. to unique types
    and for a couple things in the code generator.  This should be easy to
    synchronize on or eliminate.

2) Various passes poke at the module to get things like intrinsics,
    function declarations, etc.  I think this is easy to solve with locking
    and would be easy.

3) The use/def chain machinery in LLVM violates the principle that local
    manipulation doesn't touch global objects.  This is because
    *everything* has use/def chains, including global variables and even
    constants (e.g. 'i32 2').  Solving this is much trickier than #2, but
    seems feasible with some tricky atomic access algorithms.

-Chris

-- 
http://nondot.org/sabre/
http://llvm.org/