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-
