This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] S/390: Hardware transactional memory support
- From: Peter Bergner <bergner at vnet dot ibm dot com>
- To: Andreas Krebbel <krebbel at linux dot vnet dot ibm dot com>
- Cc: Torvald Riegel <triegel at redhat dot com>, gcc-patches at gcc dot gnu dot org
- Date: Fri, 02 Aug 2013 09:36:46 -0500
- Subject: Re: [PATCH] S/390: Hardware transactional memory support
- References: <20130621102314 dot GA753 at bart> <1375443114 dot 9970 dot 187 dot camel at triegel dot csb> <51FBB13E dot 9080403 at linux dot vnet dot ibm dot com> <1375453429 dot 5240 dot 6 dot camel at otta> <51FBC1A8 dot 1010307 at linux dot vnet dot ibm dot com>
On Fri, 2013-08-02 at 16:26 +0200, Andreas Krebbel wrote:
> On 02/08/13 16:23, Peter Bergner wrote:
> > On Fri, 2013-08-02 at 15:16 +0200, Andreas Krebbel wrote:
> >> 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.
> >
> > Except that the htm_begin() routines are declared static inline functions,
> > so when they're inlined, you aren't protected by the semantics of a call
> > anymore, are you?
>
> They get inlined into libitm code but not into the user code. As I understand it in the user code
> will always be a call to _ITM_beginTransaction.
Sure, that protects the user code, but what about the libitm code?
>From your previous comment:
> As long as libitm does not use FPRs itself this should be safe without
> having tbegin clobbering FPRs.
Is it a given that s390 doesn't use FPRs without explicit use of
floating point types? I ask, because on POWER, we can and do
generate floating point code without explicit use of double,
float, etc. Maybe s390 is safe in that respect.
Peter