[PATCH] Add HLE target feature

[Nadav Rotem]

Michael, 

Thanks for the explanation. I think that the question that we need to ask ourselves is, does this belong in the compiler ?  Before we design beautiful abstraction that will add to the complexity of the compiler we need to know if the complexity is worth it.  Michael, are you committed to doing __optimization__ work to support transactional memory ? If so, how will this work benefit others ?  To my understanding, transactional memory is not something that is going to benefit many people. 

Thanks,
Nadav

On Feb 20, 2013, at 5:34 PM, Michael Liao <michael.liao at intel.com> wrote:

> Hi Jeffery
> 
> Thanks for reminder. I will add documentation soon. So far, at IR level,
> the only change is adding a metadata (!targetflags <N>) through the
> patch. The flag word will be defined by target and not a generic one.
> 
> Target-specific flag should be helpful for other architectures, such as
> Power. The similar HLE hint could be used by target backend to replace
> regular atomic builtin with a HLE version if they have efficient TM
> support.
> 
> Yours
> - Michael
> 
> On Wed, 2013-02-20 at 17:28 -0800, Jeffrey Yasskin wrote:
>> On Wed, Feb 20, 2013 at 5:08 PM, Chandler Carruth <chandlerc at google.com> wrote:
>>> 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.
>> 
>> Oh yeah, I'd forgotten this part. Michael, could you point us to your
>> patch against http://llvm.org/docs/Atomics.html documenting your new
>> IR attributes? I didn't look through every patches, but I didn't see
>> any documentation in a brief scan.
>> 
>> Note that "Start a Hardware Lock Elision transaction with the atomic
>> operation." won't be sufficient, even if these are just
>> semantically-ignorable hints. I suspect that there's some
>> actually-useful semantics here that would make these operations usable
>> by other architectures if they ever add such instructions. For
>> example, see the documentation of the !nontemporal metadata.
>> 
>> Thanks,
>> Jeffrey
> 
> 
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130220/8dc05923/attachment.html>