[PATCH] Document HLE metadata

[Michael Liao]

Hi Nadav

Almost miss this. The motivation to hint atomic instruction is that it
make programmer's lock primitives (based on atomic instruction) works on
both targets with or without HLE support. They could follow the same
code path with just a minor flag. This approach is chosen in gcc-4.8 for
HLE support.

If different intrinsics need providing, we need at least atomicrmw
{xchg/add/sub/and/nand/or/xor} and cmpxchg for various data types.

To propagate HLE hint from LLVM IR into target code generator, I adds
HLEHint (2 bits in SubclassData) in atomic node and necessary code to
propagate them. Except that, there's nothing fancy.

Would you give more details on "moving away from SelectionDAG"? What's
the alternative?

Yours
- Michael

On Fri, 2013-03-22 at 21:35 -0700, Nadav Rotem wrote:
> Hi Michael, 
> 
> 
> I am sorry for not writing earlier about this patch.  I wanted to ask
> you why do you prefer to annotate the IR and change the SelectionDAG
> and affect all of the LLVM targets when you can simply add
> target-specific intrinsics ?  How many intrinsics do you need to
> implement the HLE instructions ? We would like to move away from
> SelectionDAG (Andy's work to remove the pre-RA scheduler is a part of
> this plan) and adding complexity to SelectionDAG would only make it
> more difficult for us in the future. 
> 
> 
> Thanks,
> Nadav
> 
> 
> 
> On Feb 27, 2013, at 12:23 PM, darkbuck <michael.hliao at gmail.com>
> wrote:
> 
> > Hi eli.friedman, chandlerc, jyasskin, nadav, hfinkel,
> > 
> > Hi All,
> > 
> > I took the advice from Jeffrey to remove the target-specific
> > metadata considering the IR portability among targets. Now, the
> > proposal is adding HLE metadata (hle.lock) on atomic instructions to
> > pass HLE hint (acquire or release). The documentation is revised
> > first and semantic of a speculative atomic instruction is added
> > within the context HLE and TM.
> > 
> > Thanks
> > - Michael
> > 
> > 
> > http://llvm-reviews.chandlerc.com/D475
> > 
> > Files:
> >  docs/LangRef.rst
> > 
> > Index: docs/LangRef.rst
> > ===================================================================
> > --- docs/LangRef.rst
> > +++ docs/LangRef.rst
> > @@ -1292,6 +1292,32 @@
> > other operations running in the same thread (for example, in signal
> > handlers).
> > 
> > +Hardware Lock Elision Hint
> > +^^^^^^^^^^^^^^^^^^^^^^^^^^
> > +
> > +Atomic instructions (:ref:`cmpxchg <i_cmpxchg>`, :ref:`atomicrmw
> > <i_atomicrmw>`,
> > +and :ref:`atomic store <i_store>`) may take an optional hint of
> > Hareware Lock
> > +Elision (Speculative Lock Elision or Transactional Lock Elision) to
> > start an
> > +HLEd critical section by *acquiring* an elided lock or end an HLEd
> > +critical section by *releasing* an elided lock.
> > +
> > +To *acquire* an elided lock, the target tries its best to execute
> > speculatively
> > +on the specified atomic variable without assuming any semantic
> > knowledge of
> > +that atomic variable. In other words, the target should not
> > interpret the value
> > +of that atomic variable. Once the speculative execution is aborted,
> > the target
> > +resumes the normal execution on that atomic variable.
> > +
> > +To *release* an elided lock, the target ends and commits the
> > speculative
> > +execution if the specified atomic variable is previously *acquired*
> > +specutively. If that atomic variable is *acquired* in real, the
> > target will
> > +*release* it by resuming the normal execution on that actomic
> > variable. A
> > +target may choose to abort a speculative execution (or transaction)
> > if the
> > +specified atomic variable cannot be restored to its original value
> > it had just
> > +before the speculative *acquiring*.
> > +
> > +See :ref:`hle.lock metadata <hle_hint>` for details on adding HLE
> > hint on
> > +atomic instructions.
> > +
> > .. _fastmath:
> > 
> > Fast-Math Flags
> > @@ -2644,6 +2670,35 @@
> >    !1 = metadata !{ metadata !1 } ; an identifier for the inner
> > parallel loop
> >    !2 = metadata !{ metadata !2 } ; an identifier for the outer
> > parallel loop
> > 
> > +.. _hle_hint:
> > +
> > +'``hle.lock``' Metadata
> > +^^^^^^^^^^^^^^^^^^^^^^^
> > +
> > +``hle.lock`` metadata may be attached only to an atomic
> > instruction. It
> > +presents the Hardware Lock Elision (HLE) hint to the backend. The
> > hint is
> > +represented as a metadata string of either ``acquire`` or
> > ``release``.
> > +
> > +``acquire``
> > +  ``acquire`` is a hint to start lock elision on the memory address
> > specified
> > +  by the atomic instruction.
> > +
> > +``release``
> > +  ``release`` is a hint to end lock elision on the memory address
> > specified by
> > +  the atomic instruction.
> > +
> > +If a target does not support HLE, the backend should ignore such a
> > hint.
> > +
> > +Examples:
> > +
> > +.. code-block:: llvm
> > +
> > +      %t4 = cmpxchg i32* @sc32, i32 0, i32 1 acquire, !hle.lock !0
> > +      store atomic i32 0, i32* @sc32 release, !hle.lock !1
> > +    ...
> > +    !0 = metadata !{metadata !"acquire"}
> > +    !1 = metadata !{metadata !"release"}
> > +
> > 
> > Module Flags Metadata
> > =====================
> > <D475.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