<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Feb 27, 2013 at 6:08 PM, Nadav Rotem <span dir="ltr"><<a href="mailto:nrotem@apple.com" target="_blank" class="cremed">nrotem@apple.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>Hi Jeffrey, </div><div><br></div><div><div class="im"><blockquote type="cite"><div style="letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">
 it's an extra argument passed through some layers and an extra level of arrays in<br>some other layers. </div></blockquote><div><br></div></div><div>This patch adds complexity to multiple layers of the compiler, and I would like to understand the motivation before we add this complexity (and compile time). </div>
</div></blockquote></div><br>Nadav, both Jeffrey and I have written several emails explaining why we think that there are some good motivations.</div><div class="gmail_extra"><br></div><div class="gmail_extra" style>Your only objections to what we've said apply equally well to atomic operations. Jeffrey, Owen, and I helped build the motivation document and spec for putting atomics support into the IR. Are you questioning the utility of having atomics modeled in LLVM? Or is there something specific to HLE that you think is questionable?</div>
<div class="gmail_extra" style><br></div><div class="gmail_extra" style>You stated that we give up and don't try to optimize atomic loads and stores, but that isn't true. We have a spec for them, and can reason precisely about their behavior as a result. I know for a fact that SROA will remove atomic loads and stores, and there are other cases as well. None of this can be true if the synchronization is implemented in inline asm as you suggest.</div>
<div class="gmail_extra" style><br></div><div class="gmail_extra" style>If you have a specific concern with HLE, please express it. Continually asserting that "this clearly belongs in a library" or other sweeping assertions isn't helping here, as the people who are responsible for building the IR's memory model and atomic model have disagreed. You're going to need to explain your reasoning here so that we can actually discuss any issue.</div>
<div class="gmail_extra" style><br></div><div class="gmail_extra" style>If you have a generic concern with being able to express the primitive operations that make up synchronization constructs in the LLVM IR, you're asking for a radical shift in direction of the project, and one which I strongly oppose. It should also be a completely separate discussion.</div>
</div>