[PATCH][RFC] HLE support proposal

[Nadav Rotem]

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. 

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 ? 

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

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130416/5c6b43f0/attachment.html>