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

Daniel Jacobowitz dan at codesourcery.com
Tue Feb 1 19:43:42 UTC 2005


On Tue, Feb 01, 2005 at 01:28:12PM +0000, Dominic Sweetman wrote:
> > There are a couple of other quirks for this; the only one I can think
> > of offhand is MIPS-I load delay slots, which would mean neither
> > sequence could be used as-is.
> 
> There are relatively few MIPS-I machines out there.  Would it be
> unacceptable if the standard NPTL system failed to work on them?

There are still plenty of non-MIPS-I configurations compiled for
MIPS-I.  I doubt that will change any time soon, so we have to be able
to cope with the load delay slots.

> > The immediate disadvantage is that the compiler can not schedule the
> > sequences.  I don't know what all the tradeoffs are here, I just
> > know that the compiler implementation would be simpler if we did not
> > make the sequences fixed and unschedulable.
> > 
> > So I'd like to ditch that unless folks think that
> >   (A) the linker optimizations are useful
> >   (B) the linker optimizations are feasible
> >   (C) someone is likely to implement the linker optimizations
> > 
> > Any opinions?  I see that Alpha does implement the TLS linker
> > relaxations; on the other hand, Alpha already had a linker relaxation
> > mechanism in place, and the GNU tools for MIPS don't.
> 
> Why not re-write the spec to say "unless you generate this sequence
> exactly like this, you'll probably prevent any future linker
> optimization from working" - and then leave it to the compiler
> toolchain. 
> 
> My opinion is that linker optimizations could be very valuable, given
> a cheap way of accessing a thread pointer.  But MIPS Technologies are
> very unlikely to do heroic work on the linker for the o32 ABI - but we
> do intend to at least try that out for our NUBI ABI.

Fine by me; if no one else responds, I'll do this.

Note that when I make this change, I'm also going to let the compiler
schedule the sequences; whoever implements the linker optimizations can
go back and undo that.

-- 
Daniel Jacobowitz



More information about the mips-tls mailing list