<div dir="ltr"><div class="gmail_extra">On Wed, Feb 20, 2013 at 4:51 PM, Jeffrey Yasskin <span dir="ltr"><<a href="mailto:jyasskin@googlers.com" target="_blank" class="cremed">jyasskin@googlers.com</a>></span> wrote:<br>
<div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=":5rc">Don't take me as authoritative, but it seems sensible to add clang and<br>
LLVM support for these instructions if there's enough of a spec for<br>
the language-level operations to describe when the compiler can<br>
optimize around them. For example, the C11 atomics allow the compiler<br>
to reorder non-atomic operations across atomic operations in certain<br>
circumstances.<br></div></blockquote><div><br></div><div style>I agree. For the primitive atomic operations which libraries for synchronization decompose into, we should have a clear semantic model that ensures optimizations on non-atomic code is not pessimized. That was a large part of the motivation behind giving LLVM a memory model and atomic operation support. I think it would be a shame for a language attempting to leverage HLE to lose the ability to represent synchronization in terms of the LLVM memory model, and consequentially for LLVM to lose the ability to optimize around the synchronization when safe[1].</div>
<div style><br></div><div style>That said, the next bit is critical:</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=":5rc">Is there a description of the language-level semantics of the<br>

operations you're adding, or does it all rely on the instruction set<br>
definition? Could a compiler decide that it's a good idea to add these<br>
prefixes on its own?<br></div></blockquote><div><br></div><div style>This is really important to get right. We need to provide a clear and carefully worded spec for this in the IR's memory model so that the set of allowed optimizations and transforms are well understood.</div>
<div style><br></div><div style>Once we have that, my hope is that the implementation of this would be relatively simple. I've not looked at the details or the patch, so I can't comment there, just that in principle this should be a relatively small added feature on top of the existing memory model and atomic operation abstractions in LLVM.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=":5rc">Note also that, if I'm remembering correctly, the __atomic_* builtins<br>
(<a href="http://gcc.gnu.org/onlinedocs/gcc-4.7.2/gcc/_005f_005fatomic-Builtins.html" target="_blank" class="cremed">http://gcc.gnu.org/onlinedocs/gcc-4.7.2/gcc/_005f_005fatomic-Builtins.html</a>)<br>
were added by gcc, and don't have quite the same semantics as the C11<br>
operations in ways I don't remember. libstdc++ compiles to these. The<br>
__c11_atomic_ builtins<br>
(<a href="http://clang.llvm.org/docs/LanguageExtensions.html#c11-atomic-builtins" target="_blank" class="cremed">http://clang.llvm.org/docs/LanguageExtensions.html#c11-atomic-builtins</a>)<br>
are what libc++ uses, and match the C11 spec very closely. That means<br>
that if gcc takes a change to the __atomic_ builtins, it's probably a<br>
good idea for Clang to take it too, even if it's not quite right<br>
semantically.</div></blockquote></div><div class="gmail_extra"><br></div>To tease this apart a bit more, there are in fact three layers:</div><div class="gmail_extra"><br></div><div class="gmail_extra" style>1) The base case: we must have a single spec for the LLVM IR model. This should be tailored to the needs of optimizers, general enough to represent the various builtins, and still support efficient lowering to both X86 and potentially PPC implementations.</div>
<div class="gmail_extra" style><br></div><div class="gmail_extra" style>2) Frontend support that matches the standards for C and/or C++ (the __c11_atomic_.... builtins in Clang today).</div><div class="gmail_extra" style>
<br></div><div class="gmail_extra" style>3) Any compatibility mappings from GCC builtins to #1 to support compiling libstdc++ (the __atomic_... builtins in Clang today).</div><div class="gmail_extra" style><br></div></div>