RFA: MIPS TLS support

Daniel Jacobowitz drow@false.org
Wed Mar 9 22:53:00 GMT 2005


On Wed, Mar 09, 2005 at 10:36:30PM +0000, Richard Sandiford wrote:
> But as I understand it, we don't ever want to treat TLS symbols
> as either legitimate constants or legitimate addresses, hence:
> 
> > -#define LEGITIMATE_CONSTANT_P(X) (mips_const_insns (X) > 0)
> > +#define LEGITIMATE_CONSTANT_P(X) (!mips_tls_operand_p (X) && mips_const_insns (X) > 0)

[Maybe mips_const_insns should be handling that check?]

> 
> and:
> 
> > +  /* Thread-local symbols must be split.  Only LD and LE have useful
> > +     LO_SUMs though.  */
> > +  mips_split_p[SYMBOL_TLS_GD] = true;
> > +  mips_split_p[SYMBOL_TLS_LD] = true;
> > +  mips_lo_relocs[SYMBOL_TLS_LD] = "%dtprel_lo(";
> > +  mips_split_p[SYMBOL_TLS_IE] = true;
> > +  mips_split_p[SYMBOL_TLS_LE] = true;
> > +  mips_lo_relocs[SYMBOL_TLS_LE] = "%tprel_lo(";
> 
> So mips_symbolic_constant_p seems to be lying when it returns true
> for zero-offset TLS symbols.  Why not simply:
> 
>   - get mips_symbolic_constant_p to return false for TLS constants
>   - get mips_const_insns to return 0 for TLS constants
>   - handle TLS symbols specially in mips_legitimize_move and
>     mips_legitimize_address (as opposed to TLS constants being
>     special cases of mips_split_p)?

Basically, because TLS access should be handled parallel to GOT access. 
It's just as much a symbolic constant as an undefined global symbol.

I originally handled it separately from mips_split_p; it turns out that
what I want to do is almost exactly the same!  The duplication
convinced me that I ought to be doing it this way.

> On the other hand:
> 
> > +(define_insn "tls_ie_<mode>"
> > +  [(set (match_operand:P 0 "register_operand" "=d")
> > +	(unspec:P [(match_operand:P 1 "register_operand" "d")
> > +		   (match_operand:P 2 "tls_symbol_ref" "")]
> > +		  UNSPEC_TLS_TPREL_HI16))]
> 
> (typo here btw: should be UNSPEC_TLS_IE)

Oops.  Harmless, but good catch.

> the idea is that every sequence apart from tls_get_tp_<mode> should
> be handled using the existing explicit reloc patterns.  There would
> be special symbol types like:
> 
>     SYMBOL_TLSGD:
>         lo_relocs: "%tlsgd("
> 
>     SYMBOL_TLSLDM:
>         lo_relocs: "%tlsldm("
> 
>     SYMBOL_DTPREL:
>         hi_relocs: "%dtprel_hi("
>         lo_relocs: "%dtprel_lo("
> 
>     SYMBOL_GOTTPREL:
>         lo_relocs: "%gottprel("
> 
>     SYMBOL_TPREL:
>         hi_relocs: "%tprel_hi("
>         lo_relocs: "%tprel_lo("
> 
> and mips_legitimize_tls_address should rewrite TLS symbolic constants
> so that they use these symbol types instead.  Doing things this way
> should also help any future MIPS16 port.

I do not remember why I didn't use the HIGH relocs.  I think it was
just easier this way; that seems like a worthwhile cleanup.  I will
try.  Ditto the other lo relocs.

> There seems to be quite a bit of cut-&-paste in the original version
> of mips_legitimize_tls_address:

Only for si vs. di instructions, if that's what you mean.  The models
really have very little in common; this won't make that function
substantially shorter.  I like keeping the different access models
separated, because this way I can read through and see what is
generated in each case.

> > +#undef TARGET_HAVE_TLS
> > +#define TARGET_HAVE_TLS HAVE_AS_TLS
> 
> Since you don't support MIPS16 yet, wouldn't it be better to set this
> to "false" in override_options if TARGET_MIPS16?  Better that than:

Oh, I can modify targetm in override_options?

-- 
Daniel Jacobowitz
CodeSourcery, LLC



More information about the Gcc-patches mailing list