On 02/08/13 13:31, Torvald Riegel wrote:
> On Fri, 2013-06-21 at 12:23 +0200, Andreas Krebbel wrote:
>> Index: libitm/config/s390/target.h
>> ===================================================================
>> *** libitm/config/s390/target.h.orig
>> --- libitm/config/s390/target.h
>> ***************
>
> [...]
>
>> + static inline uint32_t
>> + htm_begin ()
>> + {
>> + return __builtin_tbegin_nofloat (NULL);
>> + }
>
> I'm not quite sure I understand why the nofloat variant is sufficient;
> is this because we don't use FPRs in the abort/restart code of libitm
> (and the FPRs are known to be clobbered after starting a txn)?
Yes. To my understanding there are 2 potential issues when the FPRs are not
saved.
1. The abort code will read corrupted FPR content for FPRs:
- which are live across tbegin and
- are updated in the TX body and
- are read in the abort code
The abort code will see the updated value from the TX body.
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.
2. The other problem is that the ABI might get violated when aborting into a
callee which already
returned and there are FPRs which have been modified afterwards. In that case
the compiler would not
have generated FPR save/restore instructions in the function prologue/epilogue
of the callee. But in
fact there are modified FPRs when exiting the second time.
But again this should be no problem thanks to the setjmp/longjmp semantics of
_ITM_beginTransaction
and GTM_longjmp. If the TX body modified a call-saved FPR it will get restored
on the abort path
back from libitm to the user code.
As long as libitm does not use FPRs itself this should be safe without having
tbegin clobbering FPRs.
> There is a bit in the properties passed to _ITM_beginTransaction which
> states whether the txn has floating point update code
> (pr_hasNoFloatUpdate). Would this be useful?
This probably would be useful in the ITM_beginTransaction / GTM_longjmp
implementations which in
that case could try to avoid the FPR save/restores. But Richard mentioned that
these bits so far are
never set by GCC since it is lacking the required infos from the register
allocator.
> (BTW, sorry for the late response. I don't read gcc-patches frequently,
> so please CC me on libitm-related things.)
No problem. I'll try to remember this and cc you next time.
Bye,
-Andreas-
