[PATCH] Add HLE target feature

[Nadav Rotem]

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

> Hi Nadav
> 
> HLE support in these patches is neither about optimization nor
> transactional memory support in LLVM/clang. It just enables developer to
> use HLE feature across different compilers since these HLE hints won't
> change the existing atomic model.

HLE can be hidden deep inside libraries that need them. The is no need to burden the compiler with more code that will slow down the compile time, increase the binary size. Maybe I am wrong, but it is your responsibility to show why we need this in LLVM.   

> 
> Yours
> - Michael
> 
> On Wed, 2013-02-20 at 17:42 -0800, Nadav Rotem wrote:
>> 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
>> 
> 
>