[LLVMdev] Available code-generation parallelism

[Luke Dalessandro]

Jonathan Brandmeyer wrote:
> It might work for the IR construction phase, but not for optimization
> and emitting object code.  The locking issue is going to be severe
> because it will be nearly (completely?) impossible to guarantee a
> globally consistent lock order for any given def/use chain.  Therefore,
> such a solution would require a kind of high-level contention manager
> akin to software transactional memory (STM).  Even the fastest STMs in
> research are much slower than locking.  I think that there is a better
> way.

We in the TM community are always looking for "real-world" applications 
that can benefit from TM for benchmarking purposes. In the past we have 
found that unstructured graph and worklist algorithms are a prime 
example where TM can really help.

If you can provide a reference I would be interested in looking at the 
code inside LLVM for transformation/codegen passes that result in the 
problems that you describe.

-Luke

> I would like to propose a different solution: Lift all internalized
> objects to be unique at the Module level instead of globally.  This will
> require an initial pass to be performed (called IRFinalize?), and
> equality of Type objects by pointer comparison will not be valid until
> after this pass is complete.  The Module is already the unit of
> compilation once LLVM IR has been initially emitted for most cases, and
> it should be straightfoward to structure the pass such that it can work
> on single functions if the user is compiling at that level.
> 
> The IRFinalize pass can allocate the bookkeeping storage for identifying
> duplicate Constants and Types and then release it so long as none of the
> optimization and analysis passes 1) Emit new Types or 2) are broken by
> duplicate Constants.
> 
> -Jonathan
> 
> PS: What is RAUW?  I'll volunteer the clerical work of adding it to the
> Lexicon if you'd be kind enough to hand me a small dose of clue :)
> 
>> -Chris
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> 
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev