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

[Mark Mitchell]

Michael Uhler wrote:
>>From this discussion I am still inclined to stay with rdhwr.  
>>30-60 cycles is not very long.
> 
> The problem that I'm having with this email thread is that I no longer
> understand what problem is being solved.

I'll try to summarize what I understand the situation to be.

CodeSourcery has done an implementation for one of its customers using 
rdhwr.  We'd like to get that an implementation, or a variant of it, out 
to the broader community.  From our point of view, it's just as easy to 
use any other single instruction that loads the thread pointer, instead 
of "rdhwr"; that could be "lw" or some other trapping load.  There's no 
technical problem making that change.

What is important is that we get buy-in from the rest of the Linux MIPS 
community.  We really want to avoid multiple different versions of this 
stuff out there.  Concern about that issue is right now preventing 
Daniel from posting his patches; he doesn't want to see things fragment.

Daniel feels rdhwr is the best choice, as it would seem to avoid 
complexity down the road; MIPS seems to feel that the number of cycles 
required to access the thread pointer on current hardware is more 
important.  I don't think I have an opinion, but I would point out that 
(a) optimizations for TLS models mean that you can often make multiple 
accesses to TLS with a single thread pointer load, and (b) a lot of 
threaded programs make very little use of TLS, but one still needs 
*some* implementation of TLS in order to get NPTL off the ground.  Both 
of these points suggest that cycles-per-thread-pointer-load may not be 
that important a metric.  A compromise solution would be to say that the 
ABI requires "rdhwr", but mark the instruction with a dynamic relocation 
that the dynamic loader could modify into a different instruction if 
that makes sense on a particular system.

Ultimately, I think it would be most helpful would be for the Linux MIPS 
community to make a decision of what single instruction needs to go in 
that slot, and then let us know.  If, in the end, it's not rdhwr, that's 
OK.  However, Daniel's validated his changes using the rdhwr solution, 
and we don't have the resources to re-validate with another solution, 
under our existing contracts.  So, we would provide our patches to MIPS, 
and let MIPS handle the upstream submission.

-- 
Mark Mitchell
CodeSourcery, LLC
mark at codesourcery.com
(916) 791-8304