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: Torvald Riegel <triegel at redhat dot com>
- To: Andreas Krebbel <krebbel at linux dot vnet dot ibm dot com>
- Cc: gcc at gcc dot gnu dot org
- Date: Wed, 22 May 2013 11:37:16 +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> <519C89F1 dot 6060309 at linux dot vnet dot ibm dot com>
On Wed, 2013-05-22 at 11:03 +0200, Andreas Krebbel wrote:
> 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.
Andi Kleen posted a patch a while ago with an optimization to the C code
that moved the xbegin() etc. into the ITM_beginTransaction. It had some
small issues, and didn't yet made it into trunk AFAIK.
> > 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.
For very small transactions, it can certainly be a problem; for example,
if one wants to optimize custom concurrent code with transactions.
OTOH, if the use case is lock elision in existing lock-based code, then
one would probably have function calls anyway for the lock operations,
and then one would compare performance against this case too.