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