[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.
Torvald
More information about the llvm-dev
mailing list