[PATCH] Document HLE metadata

Michael Liao michael.liao at intel.com
Mon Mar 25 22:08:46 PDT 2013 

OK, I see your point on SD which eventually won't have new features
added. Bypassing SD on atomic instruction selection may be a solution,
which I once thought the future work but may needs investigating now.

Thanks
- Michael

On Mon, 2013-03-25 at 21:54 -0700, Andrew Trick wrote:
> 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
>

More information about the llvm-commits mailing list