On 14/08/13 17:33, Richard Henderson wrote:
> On 08/14/2013 05:44 AM, Torvald Riegel wrote:
>> Can we instead move the successful path of the HTM fastpath to the
>> _ITM_beginTransaction asm function, and just do the fallback and retry
>> code in beginend.cc?
>
> Certainly, but this seems like a l
On 02/08/13 23:05, Richard Henderson wrote:
> On 08/02/2013 04:45 AM, Andreas Krebbel wrote:
>> ! XCFLAGS="${XCFLAGS} -mzarch -mhtm -msoft-float"
>
> Not good, since _ITM_R{F,D,E,CF,CD,CE} should return values in
> floating point registers; similarly for the write accessors.
Right. I've rev
On 08/14/2013 05:44 AM, Torvald Riegel wrote:
> Can we instead move the successful path of the HTM fastpath to the
> _ITM_beginTransaction asm function, and just do the fallback and retry
> code in beginend.cc?
Certainly, but this seems like a larger re-design, and I was thinking of
a shorter-term
On Tue, 2013-08-13 at 12:09 -0700, Richard Henderson wrote:
> On 08/13/2013 11:26 AM, Jakub Jelinek wrote:
> > On Fri, Aug 02, 2013 at 11:05:33AM -1000, Richard Henderson wrote:
> >> On 08/02/2013 04:45 AM, Andreas Krebbel wrote:
> >>> ! XCFLAGS="${XCFLAGS} -mzarch -mhtm -msoft-float"
> >>
>
On 08/13/2013 11:26 AM, Jakub Jelinek wrote:
> On Fri, Aug 02, 2013 at 11:05:33AM -1000, Richard Henderson wrote:
>> On 08/02/2013 04:45 AM, Andreas Krebbel wrote:
>>> ! XCFLAGS="${XCFLAGS} -mzarch -mhtm -msoft-float"
>>
>> Not good, since _ITM_R{F,D,E,CF,CD,CE} should return values in
>> flo
On Fri, Aug 02, 2013 at 11:05:33AM -1000, Richard Henderson wrote:
> On 08/02/2013 04:45 AM, Andreas Krebbel wrote:
> > ! XCFLAGS="${XCFLAGS} -mzarch -mhtm -msoft-float"
>
> Not good, since _ITM_R{F,D,E,CF,CD,CE} should return values in
> floating point registers; similarly for the write acc
On 08/02/2013 04:45 AM, Andreas Krebbel wrote:
> ! XCFLAGS="${XCFLAGS} -mzarch -mhtm -msoft-float"
Not good, since _ITM_R{F,D,E,CF,CD,CE} should return values in
floating point registers; similarly for the write accessors.
r~
On Fri, 2013-08-02 at 15:16 +0200, Andreas Krebbel wrote:
> 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/
On 02/08/13 16:36, Peter Bergner wrote:
> On Fri, 2013-08-02 at 16:26 +0200, Andreas Krebbel wrote:
>> On 02/08/13 16:23, Peter Bergner wrote:
>> As long as libitm does not use FPRs itself this should be safe without
>> having tbegin clobbering FPRs.
>
> Is it a given that s390 doesn't use FPRs wi
On Fri, 2013-08-02 at 16:26 +0200, Andreas Krebbel wrote:
> On 02/08/13 16:23, Peter Bergner wrote:
> > On Fri, 2013-08-02 at 15:16 +0200, Andreas Krebbel wrote:
> >> Since libitm implements TX begins as function calls only call-saved
> >> registers can be live across a
> >> tbegin. But all the ca
On 02/08/13 16:23, Peter Bergner wrote:
> On Fri, 2013-08-02 at 15:16 +0200, Andreas Krebbel wrote:
>> 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 restore
On Fri, 2013-08-02 at 15:16 +0200, Andreas Krebbel wrote:
> 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
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
>> ***
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_
On Tue, Jul 16, 2013 at 07:39:28PM +0200, Jakub Jelinek wrote:
> Looks good to me from quick skimming.
Ok. I've applied the following patch after successful testing.
Bye,
-Andreas-
2013-07-17 Andreas Krebbel
* config/s390/s390.c: (s390_expand_builtin): Allow -mhtm to be
enab
On Tue, Jul 16, 2013 at 07:03:18PM +0200, Andreas Krebbel wrote:
> On Tue, Jul 16, 2013 at 07:24:31AM +0200, Jakub Jelinek wrote:
> > And on s/390, right now we enable HTM support in libitm when configured for
> > -march=zEC12 by default (which isn't ideal).
>
> Ok. What about the following patch
On Tue, Jul 16, 2013 at 07:24:31AM +0200, Jakub Jelinek wrote:
> And on s/390, right now we enable HTM support in libitm when configured for
> -march=zEC12 by default (which isn't ideal).
Ok. What about the following patch (untested so far)?
It basically copies what the Power folks are doing with
On Tue, 2013-07-16 at 09:49 -0500, Peter Bergner wrote:
> On Tue, 2013-07-16 at 08:08 -0400, David Edelsohn wrote:
> > Then I agree that the hunk should be reverted so that HTM does not imply
> > POWER8.
>
> Ok, I'll bootstrap and regtest just to be sure there is no unintended
> fallout for such
On Tue, 2013-07-16 at 08:08 -0400, David Edelsohn wrote:
> Then I agree that the hunk should be reverted so that HTM does not imply
> POWER8.
Ok, I'll bootstrap and regtest just to be sure there is no unintended
fallout for such a small path before committing. Thanks.
Peter
On Tue, Jul 16, 2013 at 1:24 AM, Jakub Jelinek wrote:
> On Mon, Jul 15, 2013 at 10:40:04PM -0500, Peter Bergner wrote:
>> On Mon, 2013-07-15 at 23:03 -0400, David Edelsohn wrote:
>> > On Mon, Jul 15, 2013 at 4:26 PM, Peter Bergner
>> > wrote:
>> > > David, do you prefer reverting the above hunk
On Mon, Jul 15, 2013 at 10:40:04PM -0500, Peter Bergner wrote:
> On Mon, 2013-07-15 at 23:03 -0400, David Edelsohn wrote:
> > On Mon, Jul 15, 2013 at 4:26 PM, Peter Bergner wrote:
> > > David, do you prefer reverting the above hunk from the Power HTM
> > > patch or should I add the associated -mno
On Mon, 2013-07-15 at 23:03 -0400, David Edelsohn wrote:
> On Mon, Jul 15, 2013 at 4:26 PM, Peter Bergner wrote:
> > David, do you prefer reverting the above hunk from the Power HTM
> > patch or should I add the associated -mno-* options to the building
> > of libitm?
>
> How is libitm built for
On Mon, Jul 15, 2013 at 4:26 PM, Peter Bergner wrote:
> On Mon, 2013-07-15 at 21:32 +0200, Jakub Jelinek wrote:
>> Have you considered trying it to work even when libitm itself isn't built
>> for zEC12 or later only? I mean, both the i?86/x86_64 and powerpc* libitm
>> HTM don't define htm_availab
On Mon, 2013-07-15 at 21:32 +0200, Jakub Jelinek wrote:
> Have you considered trying it to work even when libitm itself isn't built
> for zEC12 or later only? I mean, both the i?86/x86_64 and powerpc* libitm
> HTM don't define htm_available as unconditional true, they check in some way
> whether t
On Fri, Jun 21, 2013 at 12:23:14PM +0200, Andreas Krebbel wrote:
> the attached patch implements support for hardware transactional
> memory in the S/390 backend.
>
> The transactional execution facility has been made available with IBM
> Enterprise EC12. Documentation can be found in the Princip
25 matches
Mail list logo
