[PATCH] S/390: Hardware transactional memory support

[Torvald Riegel]

On Fri, 2013-08-02 at 15:16 +0200, Andreas Krebbel wrote:
> On 02/08/13 13:31, Torvald Riegel wrote:
> > On Fri, 2013-06-21 at 12:23 +0200, Andreas Krebbel wrote:
> >> Index: libitm/config/s390/target.h
> >> ===================================================================
> >> *** libitm/config/s390/target.h.orig
> >> --- libitm/config/s390/target.h
> >> ***************
> > 
> > [...]
> > 
> >> + static inline uint32_t
> >> + htm_begin ()
> >> + {
> >> +   return __builtin_tbegin_nofloat (NULL);
> >> + } 
> > 
> > I'm not quite sure I understand why the nofloat variant is sufficient;
> > is this because we don't use FPRs in the abort/restart code of libitm
> > (and the FPRs are known to be clobbered after starting a txn)?
> 
> Yes. To my understanding there are 2 potential issues when the FPRs are not saved.
> 
> 1. The abort code will read corrupted FPR content for FPRs:
> - which are live across tbegin and
> - are updated in the TX body and
> - are read in the abort code
> The abort code will see the updated value from the TX body.
> 
> Since libitm implements TX begins as function calls only call-saved registers can be live across a
> tbegin. But all the call-saved FPRs are saved in _ITM_beginTransaction and get restored when doing
> the longjmp back into the user code. So this should be no problem.
> 
> 2. The other problem is that the ABI might get violated when aborting into a callee which already
> returned and there are FPRs which have been modified afterwards. In that case the compiler would not
> have generated FPR save/restore instructions in the function prologue/epilogue of the callee. But in
> fact there are modified FPRs when exiting the second time.
> 
> But again this should be no problem thanks to the setjmp/longjmp semantics of _ITM_beginTransaction
> and GTM_longjmp. If the TX body modified a call-saved FPR it will get restored on the abort path
> back from libitm to the user code.
> 
> 
> As long as libitm does not use FPRs itself this should be safe without having tbegin clobbering FPRs.

And I suppose that even if it would use FPRs, it shouldn't ever access
memory locations touched in user code.

Thanks for the explanation.  Some of this was "obvious", sorry, but
that's what happens when a mental context switch is incomplete :)  Next
time, I'd prefer a summary of such reasoning to be added as a comment in
the source; it's just too easy to forget about all the subtleties...

> > There is a bit in the properties passed to _ITM_beginTransaction which
> > states whether the txn has floating point update code
> > (pr_hasNoFloatUpdate).  Would this be useful?
> 
> This probably would be useful in the ITM_beginTransaction / GTM_longjmp implementations which in
> that case could try to avoid the FPR save/restores. But Richard mentioned that these bits so far are
> never set by GCC since it is lacking the required infos from the register allocator.

Another thing that comes to mind is that it might be useful to put parts
of the HTM fast path into the asm pieces of _ITM_beginTransaction.  That
way, one can use exactly the amount of SW setjmp one needs given what's
easy to save/restore for the TM; this might decrease the startup costs
of a txn somewhat.  Andi Kleen posted a patch for how to do this for RTM
a while ago (but it had some issues):
http://gcc.gnu.org/ml/gcc-patches/2013-01/msg01189.html

Perhaps something along these lines (while avoiding the issues :) )
would be useful for s/390 and Power too.


Torvald