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

[Daniel Jacobowitz]

On Tue, Feb 01, 2005 at 02:43:42PM -0500, Daniel Jacobowitz wrote:
> On Tue, Feb 01, 2005 at 01:28:12PM +0000, Dominic Sweetman wrote:
> > 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.

Unfortunately, I've realized that we can't sit on this fence.  Here's a
somewhat contrived example.

int __thread a;
int *bar (void);
int *foo (int use_tls)
{
  if (use_tls)
    return &a;
  else
    return bar ();
}

foo:
	...
	.set	noreorder
	bnez	$4, .Lfunccall
	 lw	$25, %call16(bar)($28)
	.set	reorder
	lw	$25, %call16(__tls_get_addr)($28)
	addu	$4, $28, %tlsgd(a)
.Lfunccall:
	jal	$25
	...

i.e. the two calls have been tail merged.  A perfectly valid
optimization, and one that GCC theoretically could perform, though I do
not know offhand if it does.  Note that the valid TLS GD sequence,
exactly as defined by the ABI, occurs here.  Yet we can't remove the
call instruction without breaking the function.

The only way to make this work is either to mandate that an
ABI-conforming compiler can not optimize the TLS access sequences, or
to define additional relaxation marker relocations to mark valid
sequences.  Some platforms do one, some do the other.

My preference is to do the latter, which we can postpone until someone
is ready to implement them.

-- 
Daniel Jacobowitz