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

Wed Nov 7 07:00:48 PST 2012

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

-- 
Hal Finkel
Postdoctoral Appointee
Leadership Computing Facility
Argonne National Laboratory