This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: RFC: S/390 Transactional memory support - save/restore of FPRs
- From: Andreas Krebbel <krebbel at linux dot vnet dot ibm dot com>
- To: Torvald Riegel <triegel at redhat dot com>
- Cc: gcc at gcc dot gnu dot org
- Date: Wed, 22 May 2013 11:03:45 +0200
- Subject: Re: RFC: S/390 Transactional memory support - save/restore of FPRs
- References: <20130521124056 dot GA16148 at bart> <1369146488 dot 8410 dot 1064 dot camel at triegel dot csb>
On 21/05/13 16:28, Torvald Riegel wrote:
> On Tue, 2013-05-21 at 14:40 +0200, Andreas Krebbel wrote:
> You could also start with supporting s390 HTM through the transactional
> language constructs we already support (__transaction_atomic etc.) and
> libitm. The advantage would be that you can reuse quite a few bits of
> existing machinery (e.g., different fallbacks when the HTM can't execute
> a certain transaction, some analyses on the compilation side); however,
> this doesn't give programmers as much control as if using the HTM
> directly, and it requires a function call on begin and commit when using
> the current libitm ABI.
>
> (I know that this is kind of a side note, because you seem to be looking
> for a way to expose this at the granularity of HTM begin/commit builtins
> (e.g., to base lock elision implementations on top of it); but I think
> that in the long run txnal language constructs are easier for many
> users.)
The patch I have so far implements libitm HTM support for S/390 using the builtins. Very much like
it is done on x86.
> In libitm, it's probably easier to write custom assembly code for
> ITM_beginTransaction that saves/restores all additional bits not
> restored by the HTM explicitly through a partial SW setjmp. This
> approach at least worked well for AMD's ASF, which didn't even restore
> all normal registers.
Ok. I'll have a look. I haven't done measurements with libitm so far. The experiments with the
low-level builtins show that having a function call for starting and ending a transaction is a big
hit already so I didn't invest much into optimizing the libitm variant for now.
-Andreas-