[LLVMdev] Time to think about a concurrency-aware LLVM memory model?

Torvald Riegel torvald at se.inf.tu-dresden.de
Wed Jul 18 05:29:49 PDT 2007

On Friday 13 July 2007 18:46, Vikram S. Adve wrote:
> Defining a single memory model (or a set of models) for the LLVM IR
> would be a long and complex process and probably only worthwhile for
> projects that use LLVM to build a complete persistent bytecode
> language (with parallel features) and virtual machine.  Note that the
> LLVM infrastructure has features, like the IR definition and the JIT,
> to build such a language and VM, but many projects don't use those
> and of the ones that do (like the MacOS LLLVM JIT), I don't know if
> any are parallel.
> For correctly compiling and optimizing multithreaded programs in
> static compilers, the IR somehow needs to capture the *source
> language* and *target* memory models and ensure that the former is
> correctly mapped to the latter.  That can be much more flexible (and
> hopefully easier in the short term, at least for C/C++) than defining
> a single intermediate memory model for the IR.

If the IR would have to capture at least all the source language models, 
then it seems as if we still would get a single memory model for the IR. 
This of course only applies if we want the IR to really be a unification of 
all the source languages (which might not be a sensible goal).
So, IMHO, we would at least need a meta-model if we want the IR to be 
universal w.r.t. concurrency (i.e., provide more than architecture-specific 
mechanisms). This should be even more the case if hardware supports more 
than CAS etc. in the future.


More information about the llvm-dev mailing list