[PATCH] Document HLE metadata

[Andrew Trick]

On Mar 25, 2013, at 4:14 PM, Michael Liao <michael.liao at intel.com> wrote:

> 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?

The only alternative is fast-isel. As long as you support it, there shouldn't be a problem.

SelectionDAG *scheduling* is going away completely, fairly soon. SD as a whole is not going away in the foreseeable future, but we're generally trying to reduce dependence on SD and avoid piling on features. Your proposal probably doesn't count as a "feature", as long as it follows existing conventions for passing along attributes.

Why?

- Fast-isel should be better supported. Some targets may want to exclusively use it.

- We are doing more lowering with IR passes using target info including operation and type legality. This works better for loop optimizations.

- More optimizations are being done in MI. It's not just CodeGen.

- Targets may eventually want to defer some ISEL to manage pass ordering problems, which means it has to be done on MI.

- If a feature can be added in IR/MI, why add it add it somewhere that's harder to debug and maintain?

I'm probably forgetting important points. There was a BOF on this at the last dev meeting that was recorded.

-Andy

> 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
> 
> 
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits