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: Richard Henderson <rth at redhat dot com>
- Cc: gcc at gcc dot gnu dot org
- Date: Wed, 22 May 2013 11:23:08 +0200
- Subject: Re: RFC: S/390 Transactional memory support - save/restore of FPRs
- References: <20130521124056 dot GA16148 at bart> <519BB682 dot 2050307 at redhat dot com>
On 21/05/13 20:01, Richard Henderson wrote:
> On 05/21/2013 05:40 AM, Andreas Krebbel wrote:
>> Hi,
>>
>> I'm currently implementing support for hardware transactional memory
>> in the S/390 backend and ran into a problem with saving and restoring
>> the floating point registers.
>>
>> On S/390 the tbegin instruction starts a transaction. If a subsequent
>> memory access collides with another the transaction is aborted. The
>> execution then continues *after* the tbegin instruction. All memory
>> writes after the tbegin are rolled back, the general purpose registers
>> selected in the tbegin operand are restored, and the condition code is
>> set in order indicate that an abort occurred. What the code then is
>> supposed to do is to check the condition code and either jump back to
>> the transaction if it is a temporary failure or provide an alternate
>> implementation using e.g. a lock.
>>
>> Unfortunately our tbegin instruction does not save the floating point
>> registers leaving it to the compiler to make sure the old values get
>> restored. This will be necessary if the abort code relies on these
>> values and the transaction body modifies them.
>>
>> With my current approach I try to place FPR clobbers to trigger GCC
>> generating the right save/restore operations. This has some
>> drawbacks:
>>
>> - Bundling the clobbers with the tbegin causes FPRs to be restored
>> even in the good path (the transaction never aborts).
>
> This is the only path I'd recommend for trying to implement tbegin as an intrinsic.
Mmmh ok. Where do you think the other approach (clobber in abort code + abnormal edge) could break?
I think it is important to make the good path as fast as possible in order to give transactions a
chance. Restoring the FPRs even for transactions never dealing with FPRs is quite a penalty. On
S/390 we do not have a load multiple for that :(
> That said, enabling support for tbegin in libitm doesn't really require any
> intrinsics. The simplest way is to just use inline assembly with the htm_*
> inlines we define in the config file. I don't believe you'll need to worry
> about the FPRs at all because we'll have performed a setjmp on the way in, and
> a longjmp on the way out, that will restore them properly.
Right. Since the wrapper functions already do a lot of reg save/restore having them in the builtin
again would be redundant.
-Andreas-