[mips-tls] A couple of potential changes to the MIPS TLS ABI

[Thiemo Seufer]

Michael Uhler wrote:
> The one area that I'm concerned about is the use of rdhwr to return the
> pointer.  There are several reasons why I'm not sure this is the right thing
> to do:
> 
> - rdhwr is a MIPS32/64 Release 2 instruction.  No existing MIPS I-IV
> implementation has this instruction and probably never will.  Even existing
> MIPS3264 Release 2 implementations don't have the internal register to hold
> the data.  This means that it will be years before any hardware will support
> the feature, and that support depends on an architecture decision (see next
> item)

Yes. This means we will have a TLS register which is a bit slower than
a regular GPR for MIPS{32,64}R2 and a relatively slow emulated register
for older implementations. If we use a pseudo-syscall instead, we'll
have only the second variant with less performance potential.

> - We have some concerns at the architecture level about using rdhwr for this
> purpose rather than using a GPR under the umbrella of an ABI re-work that
> some of you are involved in.

The ABI re-work surely isn't mutually exclusive to o32 TLS. The main
reason for o32 TLS is to get rid of unmaintained linuxthreads while
maintaining source-level compatibility. It will also be available soon
(the same rationale applies to n32/n64 TLS, of course). The ABI re-work
is much more ambitious.

> - Some preliminary work at MIPS suggests that a tuned handler for syscall is
> faster than one for handling rdhwr at the reserved instruction handler.
> This means that we're betting on having actual hardware implementations of
> rdhwr out there in sufficient volume to make up for the fact that we're
> penalizing everybody else by using an RI trap hander vs. a syscall trap
> handler.

That's surprising, at least for the current Linux implementation. The
basic exception handler is the same, and the syscall path is already
time-critical and loaded with ABI dispatch etc. Adding another path
to it will penalize syscalls further. RI has no critical path yet,
adding the rdhwr emulation should be fast and relatively
straightforward. Extracing the instruction from mapped space could
get slow if it interferes with TLB handling, but I don't think that's
the common case.

> To me, all of these suggest that we may want to use syscall rather than
> rdhwr to get the pointer,

I nany case it should be easy to try both and see what works better,
once the rest of the Userland implementation is working.

> at least until we can decide whether to dedicate a GPR for this purpose.

Is there some data available how much pressure has to be expected for
the TLS register vs. normal GPR? I would guess it is significantly
lower, since there are several Linux implementations which use
emulation sucessfully. In that case, rdhwr might be even benefical for
the ABI re-work, and free up an GPR which can be used for better things.


Thiemo