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 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.

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.

In extremis, I suppose you might have to compile beginend.cc with fpu registers
disabled, but even that might not be necessary.


r~


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