Re: [PATCH] fix SMP TLB optimisations

On 2/25/07, John David Anglin <[email protected]> wrote:
> 00000000 <syscall>:
>    0:   0f d9 12 81     stw r25,-10(sp)
>    4:   27 c1 10 16     fldw -10(sp),fr22
>    8:   6b c2 3f d9     stw rp,-14(sp)
>    c:   08 18 02 59     copy r24,r25
>   10:   6f c3 00 80     stw,ma r3,40(sp)
>   14:   08 17 02 58     copy r23,r24
>   18:   08 1a 02 5c     copy r26,ret0
>   1c:   4b d5 3f 09     ldw -7c(sp),r21
>   20:   4b d6 3f 11     ldw -78(sp),r22
>   24:   4b d7 3f 19     ldw -74(sp),r23
>   28:   27 c1 12 16     fstw fr22,-10(sp)
>   2c:   0f c1 10 9a     ldw -10(sp),r26
>   30:   08 00 02 40     nop
>   34:   e4 00 82 00     be,l 100(sr2,r0),sr0,r31
>   38:   08 1c 02 54     copy ret0,r20
>
> The branch to the gateway page always seems to be preceded by a nop.

Because this is non-PIC code the save/restore of r19 has been turned
into a NOP. In glibc I am heading in the direction of treating a
syscall as the equivalent of a function call.

> It could be replaced by a mtsp instruction:
>
>         mtsp %r0,%sr2
>
> This would ensure that sr2 is always set correctly for the branch to
> the gateway page.

... only for people with a recent enough glibc.

> Personally, I would like to see sr0 through sr3 available for general
> use.  I would also sr4 through sr7 to be stable (i.e., not change during
> the lifetime of an application).  Obviously, sr0 through sr3 would
> be call clobbered.
>
> Don't like what's going on with fr22 in the above code.  Seems like a
> GCC optimization bug since it looks like there are a few general registers
> that could be used.

Why a bug? It's a register just like any other.

c.