[LLVMdev] Available code-generation parallelism
gohman at apple.com
Fri Nov 7 08:50:18 PST 2008
On Nov 6, 2008, at 1:15 PM, heisenbug wrote:
> On Nov 6, 4:22 am, Jonathan Brandmeyer <jbrandme... at earthlink.net>
>> On Mon, 2008-11-03 at 23:59 -0800, Chris Lattner wrote:
>>> On Nov 3, 2008, at 3:55 PM, heisenbug wrote:
>>>> What about "inventing" pseudo-constants (which point to the right
>>>> thing) and build the piece of IR with them. When done, grab mutex
>>>> RAUW it in. Alternatively, submit to a privileged thread that
>>>> the RAUW.
>>>> The trick is to prepare the def/use chain(s) to a degree that the
>>>> mutex is only held a minimal time. If only IR-builder threads are
>>>> running concurrently there is no danger that a real constant
>>>> leaving behind a stale reference from a pseudo-constant.
>>> That could work. It would also have to be done for global values as
>>> well, and inline asm objects etc. However, I don't see any show-
>>> stoppers. The implementation could be tricky, but a nice property
>>> your approach is that the single threaded case could be made
>>> particularly fast (instead of doing atomic ops or locking always).
>> It might work for the IR construction phase, but not for optimization
>> and emitting object code. The locking issue is going to be severe
> When optimization is done, you can certainly go on and emit code
> in parallel for many functions. Since the IR is not mutated any
> more, nothing needs to be locked. I believe the SDGraphs can be
> isolated from each other. But Dan may know better...
SelectionDAGs have a few things that are globally uniqued as well,
such as type lists, but those could be fixed if needed. Also, the
pool-allocated memory is currently reused for each SelectionDAG,
though that could easily be reorganized in order to allow multiple
SelectionDAGs to be processed at the same time.
SelectionDAGs do contain references back to the LLVM IR for some
things, and there are some situations where new LLVM IR Constants
are created during SelectionDAG processing.
More information about the llvm-dev