This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: RFC: S/390 Transactional memory support - save/restore of FPRs


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-


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]