[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