[PATCH] Add HLE target feature

Michael Liao michael.liao at intel.com
Wed Feb 20 16:59:01 PST 2013


These patches are developed to follow GCC's approach supporting HLE. It
provides extra target-specific flags ORed with memory order word in
__atomic* builtins, e.g.

__atomic_fetch_add(p, 1, memory_order_seq_cst | __ATOMIC_HLE_ACQUIRE__)

will generate 'lock xacquire inc' from the previous 'lock inc' to direct
processor the additional HLE hints.

So far, it's developer's responsibility to specify HLE attributes on
their __atomic* usage.

Clang supports both C11 atomics as well as GCC's __atomic* builtins.
These patchs enabling HLE will keep clang consistent with GCC HLE
support.

Yours
- Michael

On Wed, 2013-02-20 at 16:51 -0800, Jeffrey Yasskin 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.
> 
> 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?
> 
> 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.
> 
> Jeffrey
> 
> On Wed, Feb 20, 2013 at 4:21 PM, Michael Liao <michael.liao at intel.com> wrote:
> > Hi Nadav
> >
> > So far, all __atomic__* LLVM/Clang are handled by backend to generate
> > corresponding machine code instead of calling a library function. Do you
> > mean you want to all __atomic__* to be redirected to a library call?
> >
> > Yours
> > - Michael
> >
> > On Wed, 2013-02-20 at 16:18 -0800, Nadav Rotem wrote:
> >> I understand.  This sounds like something that should belong to a library (using inline assembly), and not be a part of the compiler. I don't think that it justifies the added complexity to the compiler.
> >>
> >> Thanks,
> >> Nadav
> >>
> >> On Feb 20, 2013, at 3:05 PM, Michael Liao <michael.liao at intel.com> wrote:
> >>
> >> > Hi Nadav
> >> >
> >> > HLE is different from regular transactional memory which requires new
> >> > primitive being used by developers. HLE distinguishs that by adding hint
> >> > into existing atomic builtins (__atomic__* builtins) which are used to
> >> > implement mutex, lock, and other synchronization primitives. All these
> >> > atomic builtins are inlined and generated by LLVM backend. With the
> >> > extra HLE hint (XACQ/XREL), the processor treats the previous critical
> >> > section as a transactional section, abort it if conflicts or commit it
> >> > once XREL hint is found without conflicts. The series of patches is to
> >> > enable code generation HLE-hinted atomic builtins. Let me whether it
> >> > justifies the motivation of adding them into LLVM.
> >> >
> >> > Thanks
> >> > - Michael
> >> >
> >> > On Wed, 2013-02-20 at 14:22 -0800, Nadav Rotem wrote:
> >> >> Hi Michael,
> >> >>
> >> >> I wrote you yesterday but you may have missed my email. Why do you want to add transactional memory support to LLVM ?  Can't you implement transactional memory using a library call ?  Judging by the number of patches it looks like a major change to LLVM, and I am not sure that I understand the motivation for including it in LLVM.
> >> >>
> >> >> Thanks,
> >> >> Nadav
> >> >>
> >> >>
> >> >> On Feb 20, 2013, at 2:17 PM, darkbuck <michael.hliao at gmail.com> wrote:
> >> >>
> >> >>> Hi nadav,
> >> >>>
> >> >>> Add 'FeatureHLE' and auto-detection support
> >> >>>
> >> >>> http://llvm-reviews.chandlerc.com/D437
> >> >>>
> >> >>> Files:
> >> >>> lib/Target/X86/X86.td
> >> >>> lib/Target/X86/X86InstrInfo.td
> >> >>> lib/Target/X86/X86Subtarget.cpp
> >> >>> lib/Target/X86/X86Subtarget.h
> >> >>>
> >> >>> Index: lib/Target/X86/X86.td
> >> >>> ===================================================================
> >> >>> --- lib/Target/X86/X86.td
> >> >>> +++ lib/Target/X86/X86.td
> >> >>> @@ -120,6 +120,8 @@
> >> >>>                                      "Support BMI2 instructions">;
> >> >>> def FeatureRTM     : SubtargetFeature<"rtm", "HasRTM", "true",
> >> >>>                                      "Support RTM instructions">;
> >> >>> +def FeatureHLE     : SubtargetFeature<"hle", "HasHLE", "true",
> >> >>> +                                      "Support HLE">;
> >> >>> def FeatureADX     : SubtargetFeature<"adx", "HasADX", "true",
> >> >>>                                      "Support ADX instructions">;
> >> >>> def FeatureLeaForSP : SubtargetFeature<"lea-sp", "UseLeaForSP", "true",
> >> >>> @@ -201,7 +203,7 @@
> >> >>>                               FeatureRDRAND, FeatureF16C, FeatureFSGSBase,
> >> >>>                               FeatureMOVBE, FeatureLZCNT, FeatureBMI,
> >> >>>                               FeatureBMI2, FeatureFMA,
> >> >>> -                               FeatureRTM]>;
> >> >>> +                               FeatureRTM, FeatureHLE]>;
> >> >>>
> >> >>> def : Proc<"k6",              [FeatureMMX]>;
> >> >>> def : Proc<"k6-2",            [Feature3DNow]>;
> >> >>> Index: lib/Target/X86/X86InstrInfo.td
> >> >>> ===================================================================
> >> >>> --- lib/Target/X86/X86InstrInfo.td
> >> >>> +++ lib/Target/X86/X86InstrInfo.td
> >> >>> @@ -603,6 +603,7 @@
> >> >>> def HasBMI       : Predicate<"Subtarget->hasBMI()">;
> >> >>> def HasBMI2      : Predicate<"Subtarget->hasBMI2()">;
> >> >>> def HasRTM       : Predicate<"Subtarget->hasRTM()">;
> >> >>> +def HasHLE       : Predicate<"Subtarget->hasHLE()">;
> >> >>> def HasADX       : Predicate<"Subtarget->hasADX()">;
> >> >>> def FPStackf32   : Predicate<"!Subtarget->hasSSE1()">;
> >> >>> def FPStackf64   : Predicate<"!Subtarget->hasSSE2()">;
> >> >>> Index: lib/Target/X86/X86Subtarget.cpp
> >> >>> ===================================================================
> >> >>> --- lib/Target/X86/X86Subtarget.cpp
> >> >>> +++ lib/Target/X86/X86Subtarget.cpp
> >> >>> @@ -310,6 +310,10 @@
> >> >>>        HasBMI = true;
> >> >>>        ToggleFeature(X86::FeatureBMI);
> >> >>>      }
> >> >>> +      if ((EBX >> 4) & 0x1) {
> >> >>> +        HasHLE = true;
> >> >>> +        ToggleFeature(X86::FeatureHLE);
> >> >>> +      }
> >> >>>      if (IsIntel && ((EBX >> 5) & 0x1)) {
> >> >>>        X86SSELevel = AVX2;
> >> >>>        ToggleFeature(X86::FeatureAVX2);
> >> >>> @@ -439,6 +443,7 @@
> >> >>>  HasBMI = false;
> >> >>>  HasBMI2 = false;
> >> >>>  HasRTM = false;
> >> >>> +  HasHLE = false;
> >> >>>  HasADX = false;
> >> >>>  IsBTMemSlow = false;
> >> >>>  IsUAMemFast = false;
> >> >>> Index: lib/Target/X86/X86Subtarget.h
> >> >>> ===================================================================
> >> >>> --- lib/Target/X86/X86Subtarget.h
> >> >>> +++ lib/Target/X86/X86Subtarget.h
> >> >>> @@ -121,6 +121,9 @@
> >> >>>  /// HasRTM - Processor has RTM instructions.
> >> >>>  bool HasRTM;
> >> >>>
> >> >>> +  /// HasHLE - Processor has HLE.
> >> >>> +  bool HasHLE;
> >> >>> +
> >> >>>  /// HasADX - Processor has ADX instructions.
> >> >>>  bool HasADX;
> >> >>>
> >> >>> @@ -253,6 +256,7 @@
> >> >>>  bool hasBMI() const { return HasBMI; }
> >> >>>  bool hasBMI2() const { return HasBMI2; }
> >> >>>  bool hasRTM() const { return HasRTM; }
> >> >>> +  bool hasHLE() const { return HasHLE; }
> >> >>>  bool hasADX() const { return HasADX; }
> >> >>>  bool isBTMemSlow() const { return IsBTMemSlow; }
> >> >>>  bool isUnalignedMemAccessFast() const { return IsUAMemFast; }
> >> >>> <D437.1.patch>_______________________________________________
> >> >>> llvm-commits mailing list
> >> >>> llvm-commits at cs.uiuc.edu
> >> >>> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
> >> >>
> >> >> _______________________________________________
> >> >> llvm-commits mailing list
> >> >> llvm-commits at cs.uiuc.edu
> >> >> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
> >> >
> >> >
> >>
> >
> >
> > _______________________________________________
> > llvm-commits mailing list
> > llvm-commits at cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits





More information about the llvm-commits mailing list