[PATCH] Add HLE target feature

[Michael Liao]

Hi All

I want to clarify that the additional flags added in atomic memory order
work doesn't change the existing memory model definition but just passes
the hint to backend. It's target-specific hint based on the assumption
it won't break the well-defined model.

Yours
- Michael

On Wed, 2013-02-20 at 17:08 -0800, Chandler Carruth wrote:
> On Wed, Feb 20, 2013 at 4:51 PM, Jeffrey Yasskin
> <jyasskin at googlers.com> wrote:
>         Don't take me as authoritative, but it seems sensible to add
>         clang and
>         LLVM support for these instructions if there's enough of a
>         spec for
>         the language-level operations to describe when the compiler
>         can
>         optimize around them. For example, the C11 atomics allow the
>         compiler
>         to reorder non-atomic operations across atomic operations in
>         certain
>         circumstances.
>         
> 
> 
> 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].
> 
> 
> That said, the next bit is critical:
>  
>         Is there a description of the language-level semantics of the
>         operations you're adding, or does it all rely on the
>         instruction set
>         definition? Could a compiler decide that it's a good idea to
>         add these
>         prefixes on its own?
>         
> 
> 
> 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.
> 
> 
> 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.
>  
>         Note also that, if I'm remembering correctly, the __atomic_*
>         builtins
>         (http://gcc.gnu.org/onlinedocs/gcc-4.7.2/gcc/_005f_005fatomic-Builtins.html)
>         were added by gcc, and don't have quite the same semantics as
>         the C11
>         operations in ways I don't remember. libstdc++ compiles to
>         these. The
>         __c11_atomic_ builtins
>         (http://clang.llvm.org/docs/LanguageExtensions.html#c11-atomic-builtins)
>         are what libc++ uses, and match the C11 spec very closely.
>         That means
>         that if gcc takes a change to the __atomic_ builtins, it's
>         probably a
>         good idea for Clang to take it too, even if it's not quite
>         right
>         semantically.
> 
> 
> To tease this apart a bit more, there are in fact three layers:
> 
> 
> 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.
> 
> 
> 2) Frontend support that matches the standards for C and/or C++ (the
> __c11_atomic_.... builtins in Clang today).
> 
> 
> 3) Any compatibility mappings from GCC builtins to #1 to support
> compiling libstdc++ (the __atomic_... builtins in Clang today).
> 
>