[PATCH][RFC] HLE support proposal

[Michael Liao]

Hi Nadav

On Tue, 2013-04-16 at 22:16 -0700, Nadav Rotem wrote:
> 
> On Apr 16, 2013, at 6:34 PM, Michael Liao <michael.liao at intel.com>
> wrote:
> 
> > an alternative approach is proposed to refactor atomic
> > instruction code generation, enable HLE hint to be passed into
> > backend
> > and hence enable HLE code generation.
> > 
> 
> 
> Hi Michael, 
> 
> 
> Thanks for working on this, but I really prefer that you discuss your
> proposal with the mailing list before you send patches. You are
> putting the reviewers in a position where its difficult to make
> suggestions or propose alternatives. This is especially important for
> such intrusive patches. 

Sorry, the attached patches is for demonstration purpose only not for
the final review. As I stated in the original email, it's neither final
nor complete so far. But, with reference code, the proposal may be
understood better.

> 
> 
> Last time you sent the HLE patches I suggested that you implement HLE
> as intrinsics. I don't understand why HLE needs to be more than a
> group of intrinsics, from start-to-finish. Why do you need code other
> than intrinsics ? 

There are two considerations:

One is to provide GCC/ICC compatibility. GCC (gcc-4.8) provides HLE
functionality through existing atomic builtins by ORing HLE hint bits
into the memory order word. These builtins are implemented in LLVM/Clang
through atomic instructions. It's a straight-forward approach by hinting
atomic instructions.

The other is to provide a portable way supporting HLE in LLVM IR. With
target supporting HLE, extra HLE hints provide the performance benefit.
At the same time, the same IR will work correctly on targets without
HLE. Programmer doesn't need to ship two versions of IR if they want to
target on both processors with or without HLE.

> 
> 
> Target specific intrinsics will allow HLE-aware synchronization
> library writers and researchers who implement alternative programming
> models to use HLE.

Checking HLE hint could achieve the same purpose and, at same time, the
existing atomic semantic could be reused without checking new
intrinsics.

Yours
- Michael

> 
> 
> Thanks,
> Nadav
> 
> 
> 
> > To add minimal dependence on SelectionDAG (as we have no way to
> > bypass
> > it completely), this proposal adds series intrinsics mapping to
> > native
> > atomic intrinsics, e.g. llvm.x86.cas.* to x86's CMPXCHG and adds a
> > pass
> > just before instruction selection to transform all atomic
> > instructions
> > into target-specific native intrinsics. For atomic instructions not
> > supported directly by hardware, that pass will transform it into CAS
> > (compare-and-swap) loop or LLSC (load-link & store conditional) loop
> > after enquiring target. E.g. atomicrmw max %Ptr, %Val is not
> > directly
> > supported, it will be translated into CAS loop or LLSC loop as
> > follows:
> > 
> > ---- CAS loop ----
> > Orig := load(Ptr);
> > do {
> >  Old := PHI(Orig, Curr);
> >  New := max(Old, New);
> >  {Curr, Flag} = CAS(Ptr, Old, New);
> > } while (!Flag);
> > v := Curr;
> > 
> > where {Curr, Flag} is the return value of CAS, Curr is the current
> > value
> > in that memory and Flag indicates whether the New value is stored in
> > that location.
> > 
> > ---- LLSC loop ----
> > do {
> >  Curr := LL(Ptr);
> >  New := max(Old, New);
> >  Flag := SC(Ptr, New);
> > } while (!Flag);
> > v := Curr;
> > 
> > where Flag indicates whether the SC succeeds.
> > 
> > (LLSC is available for most RISC targets. x86 has CAS only.)
> > 
> > With this atomic IR lower pass, all atomic instructions are
> > translated
> > into target native intrinsic or code sequence based them. To get HLE
> > supported, target native intrinsics will be extended with one extra
> > parameter, HLE hint. Targets supporting HLE will lower them
> > correspondingly following target ISA spec.
> > 
> > Before completing the full patch, I attached the early patchs for
> > review
> > and demonstration purpose.
> > 
> > - 0001-Add-CAS-intrinsic-to-help-refactoring-Atomic-support.patch
> >  This patch adds llvm.x86.cas.* and llvm.x86.dcas.*, which will be
> > mapped to CMPXCHG, CMPXCHG8B, CMPXCHG16B separately.
> > 
> > - 0002-Add-X86-atomic-IR-lower-pass.patch
> >  This patch adds a pre-isel pass to lower all atomic instructions
> > into
> > target native intrinsics or CAS/LLSC loops.
> > 
> > - 0003-Add-XACQ-XREL-prefix-and-encoding-asm-printer-suppor.patch
> >  This patch adds X86 HLE instruction encoding and assembler support.
> > 
> > - 0004-Add-HLE-code-generation.patch
> >  This patch extends X86 native intrinsics to propagate HLE hint and
> > enable HLE code generation.
> > 
> > A early test case (hle-atomic-max.ll) is also added for your
> > reference.
> > 
> > Thanks for review
> > - Michael
> > 
> > 
> > 
> > <0001-Add-CAS-intrinsic-to-help-refactoring-Atomic-support.patch><0002-Add-X86-atomic-IR-lower-pass.patch><0003-Add-XACQ-XREL-prefix-and-encoding-asm-printer-suppor.patch><0004-Add-HLE-code-generation.patch><hle-atomic-max.ll>_______________________________________________
> > llvm-commits mailing list
> > llvm-commits at cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>