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

Wed Jan 30 21:58:09 PST 2013

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