[llvm-commits] [RFC] Add support of RTM from TSX

Michael Liao michael.liao at intel.com
Wed Jan 30 22:48:19 PST 2013 

On Wed, 2013-01-30 at 22:38 -0800, Nadav Rotem wrote:
> Hi, 
> 
> I am sorry for joining the conversation so late, but why do we need to add transactional memory to LLVM ?  Why can't you wrap it in some external library or inline assembly or something ?  I am not sure that you even need target specific intrinsics. You surely don't expect general optimizations to honor the semantics of transactional memory, and in that case, I am not sure that it has a place in the compiler. 

There are still chance of optimization regarding to TM to minimize the
code size / data size in a TM region by lifting non-shared memory data
access out of TM. This's the area where compiler (middle end and
backend) could help. But the current proposal just starts the marking of
TM region and misc etc.

Yours
- Michael

> 
> Nadav
> 
> 
> On Jan 30, 2013, at 9:58 PM, Hal Finkel <hfinkel at anl.gov> wrote:
> 
> > ----- Original Message -----
> >> From: "Michael Liao" <michael.liao at intel.com>
> >> To: "Hal Finkel" <hfinkel at anl.gov>
> >> Cc: "Chandler Carruth" <chandlerc at google.com>, llvm-commits at cs.uiuc.edu, "Arnamoy Bhattacharyya"
> >> <arnamoy at ualberta.ca>
> >> Sent: Wednesday, January 30, 2013 1:27:02 PM
> >> Subject: Re: [llvm-commits] [RFC] Add support of RTM from TSX
> >> 
> >> Hi Hal,
> >> 
> >> I just had a brief reading of this preliminary manual and thought it
> >> could be modelled the same way proposed previously in general.
> >> 
> >> Basically, Power's TM extension has the similar approach but adds
> >> more
> >> facility for OS, virtualization, and debug. 'tbegin', 'tend',
> >> 'tabort' (and its conditional variants) could be mapped onto
> >> 'llvm.tm.begin', 'llvm.tm.end', and 'llvm.tm.abort' (all conditional
> >> 'tabort' variants should be handled in backend to fold branch
> >> checking
> >> and 'tabort'.)
> >> 
> >> 'treclaim' and 'trechkpt' are privileged instructions and hence not
> >> used
> >> in general program or general TM-targeted programming model.
> >> 
> >> Only thing one I found quite interesting and may be worthy to be
> >> added
> >> in our target independent TM model. One usage of 'tcheck' in
> >> transactional mode is to check whether the current transion has
> >> potential to succeed. If not, the program may choose to abort
> >> transactional region earlier to reduce TM overhead. We probably
> >> provide
> >> an extra LLVM intrinsic, 'llvm.tm.check', to return 3 possible
> >> values:
> >> 'YES', 'NO', and 'UNKNOWN'. For target not being able to support
> >> this,
> >> 'UNKNOWN' should be returned. Otherwise, it will return 'YES' if the
> >> transactional region has potential to succeed and 'NO' if not.
> >> 
> >> Comments?
> > 
> > I agree; this seems perfectly reasonable. Thanks for taking the time to look at this!
> > 
> > Another difference is the concept of the "suspended" transactional states (which I think does not exist in TSX), but I think that we can reasonably omit that from the intrinsics interface.
> > 
> > -Hal
> > 
> >> 
> >> Yours
> >> - Michael
> >> 
> >> On Tue, 2013-01-29 at 22:52 -0600, Hal Finkel wrote:
> >>> Michael,
> >>> 
> >>> I think that I dropped the ball on this one. IBM recently released
> >>> a new extension to their ISA to support transactional memory
> >>> (https://www.power.org/documentation/power-isa-transactional-memory/)
> >>> -- this is different from, and hopefully will have lower overhead
> >>> compared to, what we have on the BG/Q -- and I'd like to read the
> >>> documentation and then revisit this patch.
> >>> 
> >>> Thanks again,
> >>> Hal
> >>> 
> >>> ----- Original Message -----
> >>>> From: "Michael Liao" <michael.liao at intel.com>
> >>>> To: "Hal Finkel" <hfinkel at anl.gov>
> >>>> Cc: "Chandler Carruth" <chandlerc at google.com>,
> >>>> llvm-commits at cs.uiuc.edu, "Arnamoy Bhattacharyya"
> >>>> <arnamoy at ualberta.ca>
> >>>> Sent: Wednesday, November 7, 2012 11:51:15 PM
> >>>> Subject: Re: [llvm-commits] [RFC] Add support of RTM from TSX
> >>>> 
> >>>> Here is updated patch on adding target-independent TM intrinsics
> >>>> based
> >>>> on today's discussion. In summary, a new intrinsic
> >>>> 'llvm.tm.check.mask'
> >>>> is added to interpret the return code of 'llvm.tm.begin' in a
> >>>> target
> >>>> independent manner. LangRef.html is updated with the description
> >>>> of
> >>>> these new intrinsics.
> >>>> 
> >>>> Yours
> >>>> - Michael
> >>>> 
> >>>> On Wed, 2012-11-07 at 09:00 -0600, Hal Finkel wrote:
> >>>>> ----- Original Message -----
> >>>>>> From: "Chandler Carruth" <chandlerc at google.com>
> >>>>>> To: "Michael Liao" <michael.liao at intel.com>
> >>>>>> Cc: "Hal Finkel" <hfinkel at anl.gov>, llvm-commits at cs.uiuc.edu,
> >>>>>> "Arnamoy Bhattacharyya" <arnamoy at ualberta.ca>
> >>>>>> Sent: Wednesday, November 7, 2012 2:37:09 AM
> >>>>>> Subject: Re: [llvm-commits] [RFC] Add support of RTM from TSX
> >>>>>> 
> >>>>>> Hey Michael, Hal, others!
> >>>>>> 
> >>>>>> Support for TM intrinsics seems really interesting, but I'd
> >>>>>> like
> >>>>>> to
> >>>>>> see a good (brief) write up (in the style of the common LLVM
> >>>>>> mini-RFCs
> >>>>>> to start) of the proposed holistic design of the intrinsics
> >>>>>> w.r.t.
> >>>>>> the
> >>>>>> IR model.
> >>>>>> 
> >>>>>> Some things that need to be clarified a bit here (and that I
> >>>>>> found
> >>>>>> unclear looking at the patch):
> >>>>>> 1) What are the guarantees provided by LLVM when these
> >>>>>> intrinsics
> >>>>>> are
> >>>>>> used? What are the requirements upon a particular target or
> >>>>>> runtime
> >>>>>> in
> >>>>>> order to lower them successfully?
> >>>>>> 2) What requirements are imposed on the IR optimization
> >>>>>> passes in
> >>>>>> the
> >>>>>> face of these intrinsics? What are the freedoms? How are they
> >>>>>> checked?
> >>>>>> 3) How will language TM abstractions be lowered to these
> >>>>>> constructs?
> >>>>>> IE, how would they be used in theory?
> >>>>> 
> >>>>> I haven't yet looked at Michael's patch, but this sounds like a
> >>>>> great list. These things absolutely need to be specified.
> >>>>> Thanks
> >>>>> Chandler!
> >>>>> 
> >>>>> -Hal
> >>>>> 
> >>>>>> 
> >>>>>> Other things I think are already pretty clear, but it would
> >>>>>> be
> >>>>>> useful
> >>>>>> to spell out for newcomers to the discussion such as the
> >>>>>> scope of
> >>>>>> the
> >>>>>> work, the fact that both STM and HTM are viable
> >>>>>> implementation
> >>>>>> strategies, which TM implementations are being looked at for
> >>>>>> inspiration of how to model it, etc.
> >>>>>> 
> >>>>>> I'd suggest the RFC include both the beginnings of what
> >>>>>> should
> >>>>>> eventually become a rich feature document like we have for GC
> >>>>>> (http://llvm.org/docs/GarbageCollection.html), as well as a
> >>>>>> plan
> >>>>>> for
> >>>>>> your steps in implementing it. These may be obvious, but even
> >>>>>> so
> >>>>>> it'll
> >>>>>> help telegraph what's coming. =]
> >>>>>> 
> >>>>>> -Chandler
> >>>>>> 
> >>>>>> On Wed, Nov 7, 2012 at 12:16 AM, Liao, Michael
> >>>>>> <michael.liao at intel.com> wrote:
> >>>>>>> Sorry for the late reply due to the traveling. Here is
> >>>>>>> patch
> >>>>>>> adding
> >>>>>>> the target independent TM intrinsic plus doc. Let me know
> >>>>>>> whether
> >>>>>>> it's good or not.
> >>>>>>> 
> >>>>>>> Yours
> >>>>>>> - Michael
> >>>>>>> 
> >>>>>>> -----Original Message-----
> >>>>>>> From: Hal Finkel [mailto:hfinkel at anl.gov]
> >>>>>>> Sent: Monday, November 05, 2012 11:09 PM
> >>>>>>> To: Liao, Michael
> >>>>>>> Cc: llvm-commits at cs.uiuc.edu; Arnamoy Bhattacharyya
> >>>>>>> Subject: Re: [llvm-commits] [RFC] Add support of RTM from
> >>>>>>> TSX
> >>>>>>> 
> >>>>>>> ----- Original Message -----
> >>>>>>>> From: "Michael Liao" <michael.liao at intel.com>
> >>>>>>>> To: "Hal Finkel" <hfinkel at anl.gov>
> >>>>>>>> Cc: llvm-commits at cs.uiuc.edu, "Arnamoy Bhattacharyya"
> >>>>>>>> <arnamoy at ualberta.ca>
> >>>>>>>> Sent: Friday, September 21, 2012 1:10:54 PM
> >>>>>>>> Subject: Re: [llvm-commits] [RFC] Add support of RTM from
> >>>>>>>> TSX
> >>>>>>>> 
> >>>>>>>> On Fri, 2012-09-21 at 13:00 -0500, Hal Finkel wrote:
> >>>>>>>>> Michael,
> >>>>>>>>> 
> >>>>>>>>> I am happy to see support for transactional memory, and
> >>>>>>>>> because
> >>>>>>>>> other architectures also have transactional memory
> >>>>>>>>> support
> >>>>>>>>> (like
> >>>>>>>>> the
> >>>>>>>>> IBM BG/Q with which I work), I would like to see the
> >>>>>>>>> interface
> >>>>>>>>> made
> >>>>>>>>> slightly more generic. I would like to propose the
> >>>>>>>>> following
> >>>>>>>>> interface:
> >>>>>>>>> 
> >>>>>>>>> i32 @llvm.tm.begin(i32) - The parameter here is a hint:
> >>>>>>>>> 0 ==
> >>>>>>>>> long-running transaction, 1 == short-running transaction
> >>>>>>>>> (and
> >>>>>>>>> you
> >>>>>>>>> can ignore this parameter on x86). The return value is a
> >>>>>>>>> failure
> >>>>>>>>> code.
> >>>>>>>>> We
> >>>>>>>>> can probably keep Intel's convention: if bit 0 is set
> >>>>>>>>> then
> >>>>>>>>> bits
> >>>>>>>>> 31:24
> >>>>>>>>> hold the user-defined abort code. If bit 1 is set, then
> >>>>>>>>> the
> >>>>>>>>> transaction may succeed upon retry. The exact codes are
> >>>>>>>>> otherwise
> >>>>>>>>> target-defined.
> >>>>>>>>> 
> >>>>>>>>> void @llvm.tm.end() - End the transactional region
> >>>>>>>>> 
> >>>>>>>>> void @llvm.tm.abort(i8) - The i8 is a user-defined abort
> >>>>>>>>> id
> >>>>>>>>> 
> >>>>>>>>> In short, I propose changing the names of your
> >>>>>>>>> intrinsics
> >>>>>>>>> and
> >>>>>>>>> adding
> >>>>>>>>> the long-running/short-running hint parameter to
> >>>>>>>>> begin().
> >>>>>>>>> 
> >>>>>>>>> Documentation for these would need to be added to the
> >>>>>>>>> LLVM
> >>>>>>>>> language
> >>>>>>>>> reference. For now, the compiler should probably abort
> >>>>>>>>> if
> >>>>>>>>> the
> >>>>>>>>> target
> >>>>>>>>> does not specifically handle the intrinsics.
> >>>>>>>>> 
> >>>>>>>>> Arnamoy, comments?
> >>>>>>>> 
> >>>>>>>> That's a really good idea. In fact, I didn't propose that
> >>>>>>>> because
> >>>>>>>> I
> >>>>>>>> have no idea and detailed information on how different
> >>>>>>>> hardware
> >>>>>>>> transactional memory is supported on other architectures,
> >>>>>>>> such
> >>>>>>>> as
> >>>>>>>> IBM's BG/Q and Sun's Rock.
> >>>>>>>> 
> >>>>>>>> I like this proposal and it could simplify the support of
> >>>>>>>> C++
> >>>>>>>> transaction memory onto hardware in LLVM. If no objection,
> >>>>>>>> I
> >>>>>>>> will
> >>>>>>>> start a separate patch adding these target-independent
> >>>>>>>> intrinsics.
> >>>>>>> 
> >>>>>>> Did this happen and I missed it, or have you not gotten to
> >>>>>>> this
> >>>>>>> yet?
> >>>>>>> 
> >>>>>>> Thanks again,
> >>>>>>> Hal
> >>>>>>> 
> >>>>>>>> 
> >>>>>>>> Yours
> >>>>>>>> - Michael
> >>>>>>>> 
> >>>>>>>>> 
> >>>>>>>>> -Hal
> >>>>>>>>> 
> >>>>>>>>> On Fri, 21 Sep 2012 09:57:17 -0700
> >>>>>>>>> Michael Liao <michael.liao at intel.com> wrote:
> >>>>>>>>> 
> >>>>>>>>>> Hi
> >>>>>>>>>> 
> >>>>>>>>>> Here's the patch adding RTM support from TSX[1]
> >>>>>>>>>> available
> >>>>>>>>>> in
> >>>>>>>>>> Haswell[2]. This patch adds 3 intrinsics of RTM,
> >>>>>>>>>> namely
> >>>>>>>>>> xbegin,
> >>>>>>>>>> xend, and xabort, which could be used to add hardware
> >>>>>>>>>> support
> >>>>>>>>>> for
> >>>>>>>>>> the draft
> >>>>>>>>>> C++ transaction language constructs.
> >>>>>>>>>> 
> >>>>>>>>>> Thanks for your review.
> >>>>>>>>>> - Michael
> >>>>>>>>>> 
> >>>>>>>>>> --------------
> >>>>>>>>>> [1]
> >>>>>>>>>> http://software.intel.com/sites/default/files/319433-014.pdf
> >>>>>>>>>> [2]
> >>>>>>>>>> http://software.intel.com/en-us/blogs/2012/02/07/transactional-syn
> >>>>>>>>>> chronization-in-haswell
> >>>>>>>>> 
> >>>>>>>>> 
> >>>>>>>>> 
> >>>>>>>> 
> >>>>>>>> 
> >>>>>>>> 
> >>>>>>> 
> >>>>>>> --
> >>>>>>> Hal Finkel
> >>>>>>> Postdoctoral Appointee
> >>>>>>> Leadership Computing Facility
> >>>>>>> Argonne National Laboratory
> >>>>>>> 
> >>>>>>> _______________________________________________
> >>>>>>> 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