[llvm-commits] [RFC] Add support of RTM from TSX

[Chandler Carruth]

On Wed, Jan 30, 2013 at 10:52 PM, Nadav Rotem <nrotem at apple.com> wrote:

> >
> > There are still chance of optimization regarding to TM to minimize the
> > code size / data size in a TM region by lifting non-shared memory data
> > access out of TM. This's the area where compiler (middle end and
> > backend) could help. But the current proposal just starts the marking of
> > TM region and misc etc.
>
> If you have a concrete proposal for transactional memory optimizations in
> LLVM then we can discuss it and see if it has a place in LLVM.  But until
> we have transactional memory optimizations in LLVM I think that it won't be
> a good idea to add add additional semantics to LLVM's langref.
>

I've not looked at the patch at all, just thinking about this at a
theoretical level, and I'm not sure I completely agree... I also don't
completely disagree though.

Here is my line of reasoning:

We don't really have any optimizations around atomic operations, and yet we
have a fairly precise memory model for how atomic operations on shared
memory work. While some of this is just necessary for the fundamental
operation of the optimizer to do the right things in the presence of atomic
operations in other threads, we could likely avoid most of this. However,
we don't for two reasons that occur to me:
1) It provides a useful abstraction for a frontend to use when lowering
atomic operations.
2) It exposes a reasonably detailed model to the optimizer which has the
potential for optimizing based on this (potentially in the future).

As a consequence of #2, several general purpose optimizations continue to
fire on and around atomic operations where we the generic model makes them
safe. Eventually, maybe we will get dedicated optimizations for these
operations, and maybe we won't, but I'm rather glad we didn't wait until
they existed to figure out a workable formal model for the atomics.

I feel like TM at least has the *potential* to be in a similar situation.
I'm not 100% confident of this as I mentioned initially, but it certainly
seems to have the potential for similar benefits to #1 and #2, and for
similar benefits of general purpose optimizations that would be lost if TM
is modeled via inline asm. The potential (in my mind) depends highly on
whether the representational model for TM is simple, straightforward to
reason about in the context of the existing IR, atomics, and memory model,
and maps cleanly onto hardware assisted (if not completely hardware
implemented) TM where an external function call would be an unacceptable
overhead to introduce.

Anyways, I'm curious on your thoughts, and if you disagree why. I'd like to
understand that before reasoning deeply about the specifics of the proposal.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130130/5a61ae09/attachment.html>