On 21/05/13 16:28, Torvald Riegel wrote: > On Tue, 2013-05-21 at 14:40 +0200, Andreas Krebbel wrote: > You could also start with supporting s390 HTM through the transactional > language constructs we already support (__transaction_atomic etc.) and > libitm. The advantage would be that you can reuse quite a few bits of > existing machinery (e.g., different fallbacks when the HTM can't execute > a certain transaction, some analyses on the compilation side); however, > this doesn't give programmers as much control as if using the HTM > directly, and it requires a function call on begin and commit when using > the current libitm ABI. > > (I know that this is kind of a side note, because you seem to be looking > for a way to expose this at the granularity of HTM begin/commit builtins > (e.g., to base lock elision implementations on top of it); but I think > that in the long run txnal language constructs are easier for many > users.)
The patch I have so far implements libitm HTM support for S/390 using the builtins. Very much like it is done on x86. > In libitm, it's probably easier to write custom assembly code for > ITM_beginTransaction that saves/restores all additional bits not > restored by the HTM explicitly through a partial SW setjmp. This > approach at least worked well for AMD's ASF, which didn't even restore > all normal registers. Ok. I'll have a look. I haven't done measurements with libitm so far. The experiments with the low-level builtins show that having a function call for starting and ending a transaction is a big hit already so I didn't invest much into optimizing the libitm variant for now. -Andreas-
