On Tue, Dec 13, 2011 at 12:35 PM, Richard Henderson wrote:
> On 12/12/2011 07:08 PM, David Edelsohn wrote:
>> If you don't want to grab the L2 cache line size directly, could you
>> default to 32 bytes on PPC32 and 128 bytes on PPC64 (__powerpc64__) ?
>
> Done.
Richard,
By the way, the patch is
On 12/12/2011 07:08 PM, David Edelsohn wrote:
> If you don't want to grab the L2 cache line size directly, could you
> default to 32 bytes on PPC32 and 128 bytes on PPC64 (__powerpc64__) ?
Done.
r~
On 12/13/2011 01:51 AM, Iain Sandoe wrote:
> works for me - modulo a couple of typos - probably already fixed in...
>
>> git://repo.or.cz/gcc/rth.git rth/tm-next
>
> ... but I haven't got a chance to check that out and rebuild this morning..
Thanks, no I didn't have all of these fixed.
Applied
On 13 Dec 2011, at 01:16, Richard Henderson wrote:
One more try for ppc-linux plus ppc-darwin.
I've taken care of the CALL thing and the register naming thing
since last attempt.
works for me - modulo a couple of typos - probably already fixed in...
git://repo.or.cz/gcc/rth.git rth/tm-nex
Richard,
If you don't want to grab the L2 cache line size directly, could you
default to 32 bytes on PPC32 and 128 bytes on PPC64 (__powerpc64__) ?
Thanks, David
On Mon, Dec 12, 2011 at 8:16 PM, Richard Henderson wrote:
> One more try for ppc-linux plus ppc-darwin.
>
> I've taken care of the CA
One more try for ppc-linux plus ppc-darwin.
I've taken care of the CALL thing and the register naming thing
since last attempt.
This patch should apply vs mainline, but failing that please use
git://repo.or.cz/gcc/rth.git rth/tm-next
which is what I actually tested.
r~
diff --git a/libitm/c
On 12/04/2011 01:32 PM, Iain Sandoe wrote:
> where is "_CALL_DARWIN" supposed to come from? (it is not defined by the
> preprocessor AFAICT).
>
> I can produce a patch to add it if that's an oversight in the Darwin port.
It certainly is, or is supposed to be:
> switch (rs6000_current_abi)
>
Hi Richard,
On 4 Dec 2011, at 20:45, Richard Henderson wrote:
On 12/03/2011 09:20 AM, Iain Sandoe wrote:
version 2 is a modification of your original:
a) -FRAME+BASE(r1) cannot be guaranteed to be vec-aligned in
general (it isn't on m32 darwin)
... so I've taken the liberty of rounding t
On 12/03/2011 09:20 AM, Iain Sandoe wrote:
> version 2 is a modification of your original:
>
> a) -FRAME+BASE(r1) cannot be guaranteed to be vec-aligned in general (it
> isn't on m32 darwin)
>
> ... so I've taken the liberty of rounding the gtm_buffer object and then
> pointing r4 at original
Hi Richard,
On 2 Dec 2011, at 23:36, Iain Sandoe wrote:
On 2 Dec 2011, at 22:59, Richard Henderson wrote:
I personally think the whole thing would be much easier to read
without relying on the redzone. Aside from that, there's actually
very little real difference in the two files. Essent
Once you want to check it in, consider any Darwin aspects pre-approved.
Hi Richard,
On 2 Dec 2011, at 22:59, Richard Henderson wrote:
On 12/02/2011 05:37 AM, Iain Sandoe wrote:
Richard: things that I did, intentionally, differently (and I'm not
sure are correct).
1. I saved the CR
2. Once the vrs are saved, I update the VRsave mask to reflect that.
Don't upda
On 12/02/2011 05:37 AM, Iain Sandoe wrote:
> Richard: things that I did, intentionally, differently (and I'm not sure are
> correct).
>
> 1. I saved the CR
> 2. Once the vrs are saved, I update the VRsave mask to reflect that.
Don't update VRsave. This gives the OS license to clobber those regi
On 1 Dec 2011, at 23:28, Iain Sandoe wrote:
now I'm slightly confused - do we need to preserve if across the
call or not?
erm. not well phrased.
I am trying to get a grasp on what determines the set of registers
that should be saved.
Initially, I was thinking that it was the "call-save
On 1 Dec 2011, at 22:42, Iain Sandoe wrote:
now I'm slightly confused - do we need to preserve if across the
call or not?
erm. not well phrased.
I am trying to get a grasp on what determines the set of registers
that should be saved.
Initially, I was thinking that it was the "call-sa
On 1 Dec 2011, at 20:20, Richard Henderson wrote:
On 12/01/2011 10:47 AM, Joseph S. Myers wrote:
As I previously noted in the ARM discussion, C specifically says that
setjmp/longjmp should *not* save/restore floating-point exceptions
and
rounding modes. Think of the floating-point state as
On 12/01/2011 10:47 AM, Joseph S. Myers wrote:
> As I previously noted in the ARM discussion, C specifically says that
> setjmp/longjmp should *not* save/restore floating-point exceptions and
> rounding modes. Think of the floating-point state as being a global
> variable (well, thread-local).
On Thu, 1 Dec 2011, Iain Sandoe wrote:
> However, we (on Darwin) don't seem to save the FPSCR - and there's no mention
> of it in "preserved regs" section of the ABI doc. I wonder if that's an
> oversight.
As I previously noted in the ARM discussion, C specifically says that
setjmp/longjmp sho
On Thu, Dec 1, 2011 at 10:30 AM, Richard Henderson wrote:
> I made it up. As he said, it's only used for padding to *attempt to* avoid
> false sharing. Currently sources won't actually fail with the wrong
> cacheline value, but they'll work more efficiently with the right value.
The cache li
On Thu, 2011-12-01 at 17:01 +, Iain Sandoe wrote:
> However, we (on Darwin) don't seem to save the FPSCR - and there's no
> mention of it in "preserved regs" section of the ABI doc. I wonder if
> that's an oversight.
The ppc* linux ABIs state the FPSCR is volatile, maybe it's the same
on
On 1 Dec 2011, at 16:50, Peter Bergner wrote:
On Thu, 2011-12-01 at 07:42 -0800, Richard Henderson wrote:
I didn't notice CR registers being saved in the linux setjmp
function,
but perhaps I just missed it?
I believe the setjmp/getcontext functions save the entire CR rather
than
just th
On Thu, 2011-12-01 at 07:42 -0800, Richard Henderson wrote:
> I didn't notice CR registers being saved in the linux setjmp function,
> but perhaps I just missed it?
I believe the setjmp/getcontext functions save the entire CR rather than
just the non-volatile CR fields. Looking at the glibc code,
On 12/01/2011 06:42 AM, Iain Sandoe wrote:
>> I presume that w should treat this as a normal prologue - and it
>> looks very much like "save the world" -
>
> BTW, if this is true ( i.e. we should be preserving all call-saved
> regs around the call to GTM_begin_transaction), then I guess we
> shoul
On 12/01/2011 01:42 AM, Torvald Riegel wrote:
> The ABI defines the pr_hasNoFloatUpdate and pr_hasNoVectorUpdate flags
> for _ITM_beginTransaction but we don't handle these currently. I guess
> we should do the save/restore unless those flags are set?
>
> How difficult would it be to set these fl
On 12/01/2011 06:00 AM, David Edelsohn wrote:
> On Thu, Dec 1, 2011 at 4:36 AM, Torvald Riegel wrote:
>> On Wed, 2011-11-30 at 21:41 -0500, David Edelsohn wrote:
>>> On Wed, Nov 30, 2011 at 8:05 PM, Richard Henderson wrote:
This is a tad rough, but not too bad.
>>>
>>> Cool.
>>>
>>> Maybe I
On 1 Dec 2011, at 14:04, Iain Sandoe wrote:
I presume that w should treat this as a normal prologue - and it
looks very much like "save the world" -
BTW, if this is true ( i.e. we should be preserving all call-saved
regs around the call to GTM_begin_transaction), then I guess we should
be
On 1 Dec 2011, at 01:05, Richard Henderson wrote:
No support for non-ELF, aka AIX
and Darwin. I'm not 100% sure how to handle the assembly markup
for those, and I couldn't test it anyway. Again, I'd prefer someone
else figure that stuff out.
I've started to take a look at Darwin [sjl
On Thu, Dec 1, 2011 at 4:36 AM, Torvald Riegel wrote:
> On Wed, 2011-11-30 at 21:41 -0500, David Edelsohn wrote:
>> On Wed, Nov 30, 2011 at 8:05 PM, Richard Henderson wrote:
>> > This is a tad rough, but not too bad.
>>
>> Cool.
>>
>> Maybe I don't understand what they are suppose to represent, b
On Wed, 2011-11-30 at 17:05 -0800, Richard Henderson wrote:
> Oh, for the record, I think we should probably be saving and restoring the fp
> state on all targets. If we restart a transaction, we're really saying that
> absolutely nothing happened. Something like
>
> double a, b, c;
> __tr
On Wed, 2011-11-30 at 21:41 -0500, David Edelsohn wrote:
> On Wed, Nov 30, 2011 at 8:05 PM, Richard Henderson wrote:
> > This is a tad rough, but not too bad.
>
> Cool.
>
> Maybe I don't understand what they are suppose to represent, but why
> the choice of values for cacheline size? Is that su
On Wed, Nov 30, 2011 at 8:05 PM, Richard Henderson wrote:
> This is a tad rough, but not too bad.
Cool.
Maybe I don't understand what they are suppose to represent, but why
the choice of values for cacheline size? Is that suppose to be a
value chosen by ITM or suppose to be the hardware cacheli
31 matches
Mail list logo
