[LLVMdev] interest in support for Transactional Memory?

Torvald Riegel torvald at se.inf.tu-dresden.de
Fri Oct 1 09:02:44 PDT 2010


Hi,

I would like to know whether the community is interested in getting support 
for Transactional Memory (TM) merged in upstream LLVM. TM basically gives you 
transaction properties (eg, virtually atomic + isolated execution) for 
ordinary program code. Thus, to make incrementing a counter thread-safe, you 
could say __transaction { counter++; } and the compiler would transform this 
code so that it uses a TM library, which in turn does concurrency control for 
the memory accesses in a transaction. Recent studies support the assumption 
that shared-memory synchronization with transactions is supposed to be a lot 
easier than when using locking, for example.

There seems to be interest by several large companies towards TM. Intel, 
Oracle, IBM, Red Hat, and others have been working on a specification for 
memory transactions in C++:
http://software.intel.com/file/21569
Intel, Red Hat, and my group have been working on specifying a TM library 
ABI:
http://software.intel.com/file/8097/
Intel has published an ICC prototype version with TM support, and Red Hat is 
working on TM support in the gcc "trans-memory" branch.

My group has been working on compiler support for TM for LLVM during the last 
couple of years, and we have built an LLVM-based compiler, DTMC, that covers 
both the frontend part (ie, parsing the __transaction statements and 
translating txn boundaries to IR markers) and the IR transformations 
(transforming all transactional code). The former is a patch to llvm-gcc 
(based, in turn, on gcc's TM support), but we're currently also looking at 
other options for the frontend. The latter is a normal module pass, and the 
larger part of the work.
We have also built a TM library, TinySTM++ (but TM libraries are not compiler 
specific). You can have a look at the last stable releases of the code 
(compiler and library) at http://tm.inf.tu-dresden.de


Torvald



More information about the llvm-dev mailing list