TLS register

TLS register

[Guido Guenther]

[-- Attachment #1: Type: text/plain, Size: 532 bytes --]

Hi,
Now that gcc 3.4 has incompatible ABI changes (on o32 mostly affecting
mipsel) I've been discussing with Thiemo if I'd be the right point to
take this ABI change as a possibility to additionally reserve a TLS
register. 
He suggested $24 (t8) another discussed possibility would be $27 (k1)
which is already abused by the PS/2 folks for ll/sc emulation.
Another possibility would be to reserve such a register only in the
n32/n64 ABIs and let o32 stay without __thread and TLS forever.
Any feedback welcome.
 -- Guido

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: TLS register

[Steven J. Hill]

Guido Guenther wrote:
>
> He suggested $24 (t8) another discussed possibility would be $27 (k1)
> which is already abused by the PS/2 folks for ll/sc emulation.
> Another possibility would be to reserve such a register only in the
> n32/n64 ABIs and let o32 stay without __thread and TLS forever.
> Any feedback welcome.
>
I vote for $24 (t8). LL/SC emulation is an issue and I believe some of
the exception vectors, if not all of them indirectly depend on k1. It
would take a lot of work (and testing) to rewrite the exceptions to not
utilize k1 and it would probably be a nasty performance hit in many
cases. I agree with "Screw o32" and let's move forward.

-Steve

Re: TLS register

[Ralf Baechle]

On Mon, May 31, 2004 at 08:05:24PM -0300, Guido Guenther wrote:

> Hi,
> Now that gcc 3.4 has incompatible ABI changes (on o32 mostly affecting
> mipsel) I've been discussing with Thiemo if I'd be the right point to
> take this ABI change as a possibility to additionally reserve a TLS
> register. 
> He suggested $24 (t8) another discussed possibility would be $27 (k1)
> which is already abused by the PS/2 folks for ll/sc emulation.
> Another possibility would be to reserve such a register only in the
> n32/n64 ABIs and let o32 stay without __thread and TLS forever.

Sigh, we'e been through this really often enough.  Reserving a register
comes at a price so my approach was to implement a fast path in the
exception code.  I've benchmarked that long time ago; it had less than
half the overhead than normal syscall and such a function would be subject
to normal code optimizations so calls should be few only.  Alpha already
does something similar using their PAL code.

  Ralf

Re: TLS register

[Kevin D. Kissell]

> On Mon, May 31, 2004 at 08:05:24PM -0300, Guido Guenther wrote:
> 
> > Hi,
> > Now that gcc 3.4 has incompatible ABI changes (on o32 mostly affecting
> > mipsel) I've been discussing with Thiemo if I'd be the right point to
> > take this ABI change as a possibility to additionally reserve a TLS
> > register. 
> > He suggested $24 (t8) another discussed possibility would be $27 (k1)
> > which is already abused by the PS/2 folks for ll/sc emulation.
> > Another possibility would be to reserve such a register only in the
> > n32/n64 ABIs and let o32 stay without __thread and TLS forever.
> 
> Sigh, we'e been through this really often enough.  Reserving a register
> comes at a price so my approach was to implement a fast path in the
> exception code.  I've benchmarked that long time ago; it had less than
> half the overhead than normal syscall and such a function would be subject
> to normal code optimizations so calls should be few only.  Alpha already
> does something similar using their PAL code.

The overhead realtive to a normal syscall is much less interesting
to measure than the overhead relative to having the pointer already
in a register - after all, half of a whole lot of instructions is still a whole
lot of instructions.

As some, but perhaps not all of you know, MIPS is working on
multithreaded extensions to the instruction set architecture and
the hardware, which include the ability to create and destroy
parallel threads of executioon without OS intervention in the
"expected" case (and yes, I have thought about how Linux 
could support this, but I'm not gonna go into that here).
In such a framework, it would not be acceptable to do a
system call to get a TLS value.

I don't yet have an opinion as to whether we need to retrofit
things so that user-level multithreading is compatible with o32,
but I would comment that if we go for a TLS register, k1 may 
not be a very good option. The LL/SC emulation trick with k1 
works by virtue of k1 being *destroyed* by exceptions - it doesn't 
change its status as a register reserved for kernel use.

            Regards,

            Kevin K.

Re: TLS register

[Kevin D. Kissell]

> On Mon, May 31, 2004 at 08:05:24PM -0300, Guido Guenther wrote:
> 
> > Hi,
> > Now that gcc 3.4 has incompatible ABI changes (on o32 mostly affecting
> > mipsel) I've been discussing with Thiemo if I'd be the right point to
> > take this ABI change as a possibility to additionally reserve a TLS
> > register. 
> > He suggested $24 (t8) another discussed possibility would be $27 (k1)
> > which is already abused by the PS/2 folks for ll/sc emulation.
> > Another possibility would be to reserve such a register only in the
> > n32/n64 ABIs and let o32 stay without __thread and TLS forever.
> 
> Sigh, we'e been through this really often enough.  Reserving a register
> comes at a price so my approach was to implement a fast path in the
> exception code.  I've benchmarked that long time ago; it had less than
> half the overhead than normal syscall and such a function would be subject
> to normal code optimizations so calls should be few only.  Alpha already
> does something similar using their PAL code.

The overhead realtive to a normal syscall is much less interesting
to measure than the overhead relative to having the pointer already
in a register - after all, half of a whole lot of instructions is still a whole
lot of instructions.

As some, but perhaps not all of you know, MIPS is working on
multithreaded extensions to the instruction set architecture and
the hardware, which include the ability to create and destroy
parallel threads of executioon without OS intervention in the
"expected" case (and yes, I have thought about how Linux 
could support this, but I'm not gonna go into that here).
In such a framework, it would not be acceptable to do a
system call to get a TLS value.

I don't yet have an opinion as to whether we need to retrofit
things so that user-level multithreading is compatible with o32,
but I would comment that if we go for a TLS register, k1 may 
not be a very good option. The LL/SC emulation trick with k1 
works by virtue of k1 being *destroyed* by exceptions - it doesn't 
change its status as a register reserved for kernel use.

            Regards,

            Kevin K.

Re: TLS register

[Maciej W. Rozycki]

On Tue, 1 Jun 2004, Kevin D. Kissell wrote:

> > > Now that gcc 3.4 has incompatible ABI changes (on o32 mostly affecting
> > > mipsel) I've been discussing with Thiemo if I'd be the right point to
> > > take this ABI change as a possibility to additionally reserve a TLS
> > > register. 
> > > He suggested $24 (t8) another discussed possibility would be $27 (k1)
> > > which is already abused by the PS/2 folks for ll/sc emulation.
> > > Another possibility would be to reserve such a register only in the
> > > n32/n64 ABIs and let o32 stay without __thread and TLS forever.

 For Linux the n32/n64 ABIs can be considered being in the initial stage
of deployment, so backwards compatibility is a non-issue.  Whatever is
found to be the best solution may be accepted.  So the problem of defining
a TLS pointer exists for the o32 ABI only and given the existence of
MIPS32 ISA and its implementations ignoring the issue won't only affect
ancient (but still alive) hardware.

> > Sigh, we'e been through this really often enough.  Reserving a register
> > comes at a price so my approach was to implement a fast path in the
> > exception code.  I've benchmarked that long time ago; it had less than
> > half the overhead than normal syscall and such a function would be subject
> > to normal code optimizations so calls should be few only.  Alpha already
> > does something similar using their PAL code.

 It seems a reasonable balance, IMO.

> The overhead realtive to a normal syscall is much less interesting
> to measure than the overhead relative to having the pointer already
> in a register - after all, half of a whole lot of instructions is still a whole
> lot of instructions.

 The interesting factor is how much software really needs threading.  
AFAIK, the majority does not -- I can count threaded software I know of 
(but not necessarily use) using fingers of one hand.  That does not mean 
there are no niches that make use of that approach extensively -- they 
could see a benefit, but why to penalize the rest?

> As some, but perhaps not all of you know, MIPS is working on
> multithreaded extensions to the instruction set architecture and
> the hardware, which include the ability to create and destroy
> parallel threads of executioon without OS intervention in the
> "expected" case (and yes, I have thought about how Linux 
> could support this, but I'm not gonna go into that here).
> In such a framework, it would not be acceptable to do a
> system call to get a TLS value.

 Well, this is exactly a good counter-argument for having a TLS pointer in
a gp register.  I someone needs the fastest threading possible, then let
them use the right hardware (with the threading ASE) or accept the
inefficiency of hardware that predates the concept of threading.

> I don't yet have an opinion as to whether we need to retrofit
> things so that user-level multithreading is compatible with o32,
> but I would comment that if we go for a TLS register, k1 may 
> not be a very good option. The LL/SC emulation trick with k1 
> works by virtue of k1 being *destroyed* by exceptions - it doesn't 
> change its status as a register reserved for kernel use.

 Actually the trick has never found its way into the mainline, and perhaps
it's best to keep it outside as messing with the k registers is inherently
fragile.  Of course, this applies to a possibility to use one of them for
the TLS, too. ;-)

  Maciej

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: TLS register

[David Daney]

Maciej W. Rozycki wrote:

>On Tue, 1 Jun 2004, Kevin D. Kissell wrote:
>
>  
>
>>>>Now that gcc 3.4 has incompatible ABI changes (on o32 mostly affecting
>>>>mipsel) I've been discussing with Thiemo if I'd be the right point to
>>>>take this ABI change as a possibility to additionally reserve a TLS
>>>>register. 
>>>>He suggested $24 (t8) another discussed possibility would be $27 (k1)
>>>>which is already abused by the PS/2 folks for ll/sc emulation.
>>>>Another possibility would be to reserve such a register only in the
>>>>n32/n64 ABIs and let o32 stay without __thread and TLS forever.
>>>>        
>>>>
>
> For Linux the n32/n64 ABIs can be considered being in the initial stage
>of deployment, so backwards compatibility is a non-issue.  Whatever is
>found to be the best solution may be accepted.  So the problem of defining
>a TLS pointer exists for the o32 ABI only and given the existence of
>MIPS32 ISA and its implementations ignoring the issue won't only affect
>ancient (but still alive) hardware.
>

There are MIPS32 ISA processors that are used in embedded devices that 
are far from "ancient" as some are only starting to enter the market, 
and are still in production.

For these types of devices it is not so important to maintain backwards 
compatibility with legacy tool chains and/or binary library code.  A new 
ABI very similar to o32 but with a TLS pointer in a register (perhaps 
"o32-tls") might be useful.
.
.
.

> The interesting factor is how much software really needs threading.  
>AFAIK, the majority does not -- I can count threaded software I know of 
>(but not necessarily use) using fingers of one hand.  That does not mean 
>there are no niches that make use of that approach extensively -- they 
>could see a benefit, but why to penalize the rest?
>
>  
>
Almost any non-trivial program written in java could benefit from faster 
TLS.  The java support in GCC-3.4 now allows us to write useful programs 
for MIPS in java.

David Daney.