<div dir="ltr">On Wed, Jan 30, 2013 at 10:52 PM, Nadav Rotem <span dir="ltr"><<a href="mailto:nrotem@apple.com" target="_blank" class="cremed">nrotem@apple.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">><br>
> There are still chance of optimization regarding to TM to minimize the<br>
> code size / data size in a TM region by lifting non-shared memory data<br>
> access out of TM. This's the area where compiler (middle end and<br>
> backend) could help. But the current proposal just starts the marking of<br>
> TM region and misc etc.<br>
<br>
</div>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.<br>
</blockquote><div><br></div><div style>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.</div>
<div style><br></div><div style>Here is my line of reasoning:</div><div style><br></div><div style>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:</div>
<div style>1) It provides a useful abstraction for a frontend to use when lowering atomic operations.</div><div style>2) It exposes a reasonably detailed model to the optimizer which has the potential for optimizing based on this (potentially in the future).</div>
<div style><br></div><div style>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.</div>
<div style><br></div><div style>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.</div>
<div style><br></div><div style>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.</div></div></div></div>