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

[Mark Mitchell]

Michael Uhler wrote:
> Both points are valid.  But they assume that if we DO have a performance
> problem, we'll be able to go back and fix that problem with an alternative
> method (something other than a new ABI).  It was my impression that we were
> discussing something that was not going to be easy to change once defined.

That's why I suggested, as a possible compromise, that we require that 
compilers/linkers mark the rdhwr instruction with a relocation.  That 
would allow dynamic linkers to make appropriate changes to the code, if 
appropriate.

To me, this seems like a very practical way of moving forward with our 
current implementation, while hedging our bets; what do you and others 
think?

> If we're not prepared to change things if we find a performance problem, I
> wonder why the burden of proof is on us to prove that we're not at a
> competitive disadvantage (something the ARM folks are obviously concerned
> about also) vs. the burden of proof being on having sufficient performance
> analysis to know that it will be fine.

I desparately want to avoid getting into an ARM/MIPS controversy.

(CodeSourcery is not an advocate for one architecture over the other; we 
are pleased to work with many major semiconductor vendors, and while 
loyal to each of our customers, neutral overall.)

However, I will say that the ARM GNU/Linux community and ARM, Ltd., are 
not necessarily of one mind on this topic.  I believe (thought I 
certainly cannot speak for them) that ARM, Ltd., is OK with the 
requirement that, to get maximum NPTL/TLS performance, you use an ARM V6 
chip and the new ARM ABI, including a coprocessor-read instruction to 
access the thread pointer.  The ARM GNU/Linux commmunity seems to have a 
greater attachment to the old ABI and a greater desire to hardware 
without the appropriate coprocessors.

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