[PATCH] Add HLE target feature

[Chandler Carruth]

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).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130220/dcd7c6fb/attachment.html>