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

Wed Nov 7 07:06:39 PST 2012

I see there're two separate issue: a general target independent TM support in LLVM (clang in the future) and a target specific one (RTM support, which follows ISA spec). The patch submitted last night only starts to address the former one suggested by Hal. Thanks for good suggestion, we will address them in the general target independent TM support.

Yours
- Michael

-----Original Message-----
From: Chandler Carruth [mailto:chandlerc at google.com] 
Sent: Wednesday, November 07, 2012 12:37 AM
To: Liao, Michael
Cc: Hal Finkel; llvm-commits at cs.uiuc.edu; Arnamoy Bhattacharyya
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?

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