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

Nadav Rotem nrotem at apple.com
Wed Jan 30 22:52:52 PST 2013 

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

> 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