[llvm-commits] [RFC] Add support of RTM from TSX
Hal Finkel
hfinkel at anl.gov
Wed Jan 30 23:38:33 PST 2013
----- Original Message -----
> From: "Nadav Rotem" <nrotem at apple.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: Thursday, January 31, 2013 12:52:52 AM
> Subject: Re: [llvm-commits] [RFC] Add support of RTM from TSX
>
> >
> > 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.
>
> If you have a concrete proposal for transactional memory
> optimizations in LLVM then we can discuss it and see if it has a
> place in LLVM. But until we have transactional memory optimizations
> in LLVM I think that it won't be a good idea to add add additional
> semantics to LLVM's langref.
I think that we'd like to make a reasonable attempt to provide a portable interface to these intrinsics. Can this be done with a library? Yes and no. The ultimate promise of low-overhead transactional memory is to allow for automated parallelization; forcing this unnecessarily to go through a runtime library defeats much of the low-overheadness that is crucial to its success. In addition, you'd like the compiler to be able to optimize away certain constructs certain to appear after inlining such as:
try {
... (unconditionally reaches)
abort;
}
and
try {
try {
...
}
}
(there is nothing in the outer transaction except for the inner transaction) -- the nesting can be removed
the maintenance overhead of adding well-defined target-independent intrinsics appears minimal, and has important advantages, so I think that we should do it.
Thanks again,
Hal
>
> > 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