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

[Michael Uhler]

> Yes, and nobody backs up this concern with hard data. 
> Maciej's numbers are good to know, but they tell nothing 
> about how heavily the TLS implementation will be used in 
> real-world applications.

> The assumption of "competitive disadvantage" is AFAICS 
> unproven, and the schemes suggested to improve TLS 
> performance may well turn out as over-engineering. Using e.g. 
> a wired TLB is known to have a performance impact for all 
> applications, the same is (probably to a lesser extent) true 
> for reserving a GPR.

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.

So if we are proposing something that uses trap-and-emulate of rdhwr (whose
register number will still have to change - I'll figure out what that is) as
an initial proposal, and we're prepared to change it to address any
performance problem that we find, I'm OK with that.

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.

To me, it all comes down to whether this is a final, unchangable, solution
or not.

/gmu
---
Michael Uhler, Chief Technology Officer
MIPS Technologies, Inc.   Email: uhler at mips.com
1225 Charleston Road      Voice:  (650)567-5025   FAX:   (650)567-5225
Mountain View, CA 94043   Mobile: (650)868-6870   Admin: (650)567-5085