[RFC] Port libitm to powerpc

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 update VRsave.  This gives the OS license to clobber those  
> registers on task switch, which means that you'd need to reload all  
> of those registers and restore VRsave after calling  
> _GTM_begin_transaction.

thanks (will fix when updating).

>> +	mffs f0
>> +	stfd f31,-8(r1)
>
> You didn't actually save FPSCRS, only copied it to f0.

it's saved after the stack is updated - because of being outside the  
red zone.

>> +#ifdef __ppc64__
>> +  double fpscr;			/* ??? should we save this.  */
>> +  unsigned int vscrpad;	
>> +  unsigned int vscr;		/* VRsave */
>> +#else
>> +  double fpscr;			/* ??? should we save this.  */
>> +  unsigned int vscrpad[2];	
>> +  unsigned int vscr;		/* VRsave */
>> +#endif
>
> Why the difference?

...because the VRsave reg is included in the red-zone for m32 but not  
for m64...

it also makes the alignment padding explicit ...

>> +  unsigned int cr;		/* Saved CR.  */
>> +#ifdef __ppc64__
>> +  unsigned int crpad;
>> +#endif
>
> Why not just make it unsigned long and be done with it?  There's  
> nothing saying that you can't use lg/stg for the gp that holds the  
> crs.  Nothing except for your corresponding longjmp cares about the  
> layout.

yeah .. it got like that because of ...

> 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.  Essentially, you're  
> storing the registers in a different order because the prologue  
> does, just so you can make use of the redzone.

OK -  I guess I got carried away with thinking that I might be able to  
re-use the save_world () routine - but that doesn't look feasible  
after all so....

> The aix abi saves r2; darwin 32-bit saves r13.  One extra register  
> in both cases, which could use the same slot.

... will take another look tomorrow....
.... although we still have some syntax issues that might make sharing  
the original code somewhat ugly....

====

... in the meantime, I found two obvious stupid typos in my current  
version - the attached runs without any (unexpected) fails;

Iain

Native configuration is powerpc-apple-darwin9

                 === libitm tests ===

Schedule of variations:
     unix/-m32
     unix/-m64

Running target unix/-m32
Using /usr/local/dejagnu-1-4-4/share/dejagnu/baseboards/unix.exp as  
board description file for target.
Using /usr/local/dejagnu-1-4-4/share/dejagnu/config/unix.exp as  
generic interface file for target.
Using /GCC/gcc-live-trunk/libitm/testsuite/config/default.exp as tool- 
and-target-specific interface file.
Running /GCC/gcc-live-trunk/libitm/testsuite/libitm.c/c.exp ...
Running /GCC/gcc-live-trunk/libitm/testsuite/libitm.c++/c++.exp ...
WARNING: libitm.c++/static_ctor.C compilation failed to produce  
executable

                 === libitm Summary for unix/-m32 ===

# of expected passes            23
# of expected failures          5
Running target unix/-m64
Using /usr/local/dejagnu-1-4-4/share/dejagnu/baseboards/unix.exp as  
board description file for target.
Using /usr/local/dejagnu-1-4-4/share/dejagnu/config/unix.exp as  
generic interface file for target.
Using /GCC/gcc-live-trunk/gcc/testsuite/config/default.exp as tool-and- 
target-specific interface file.
WARNING: libitm.c++/static_ctor.C compilation failed to produce  
executable

                 === libitm Summary for unix/-m64 ===

# of expected passes            23
# of expected failures          5

                 === libitm Summary ===

# of expected passes            46
# of expected failures          10

[RFC] Port libitm to powerpc

Commit Message

Patch