atom feed5 messages in com.googlegroups.llvm-dev[LLVMdev] interest in support for Tra...
FromSent OnAttachments
Torvald RiegelOct 1, 2010 9:02 am 
Duncan SandsOct 26, 2010 5:33 am 
Torvald RiegelOct 27, 2010 5:01 am 
Garrison VennOct 27, 2010 5:30 am 
Torvald RiegelOct 27, 2010 5:54 am 
Subject:[LLVMdev] interest in support for Transactional Memory?
From:Torvald Riegel ("
Date:Oct 1, 2010 9:02:44 am


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++: Intel, Red Hat, and my group have been working on specifying a TM library ABI: 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