RFA: MIPS TLS support

[Daniel Jacobowitz]

On Thu, Mar 10, 2005 at 03:08:51PM +0000, Richard Sandiford wrote:
> Daniel Jacobowitz <drow@false.org> writes:
> > So, um... why the heck is a TLS symbol not a legitimate constant, if a
> > symbol whose address needs to be loaded from the GOT is?  I have never
> > grokked that.
> 
> I thought it was because reload can't generate new references to TLS
> variables whereas it can generate new references to global symbols.

That doesn't make much sense.  They're both symbols.

> 
> >> Note also that all the symbol types currently returned by
>                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> >> mips_classify_symbol are legitimate move_operands under some
>    ^^^^^^^^^^^^^^^^^^^^
> >> configuration or other.  TLS symbols on the other hand are never
> >> legitimate move_operands.
> 
> Note the highlighted text.  So...
> 
> > That's only true via some sketchy reasoning.  Consider
> > SYMBOL_GOTOFF_LOADGP.
> 
> ...I don't understand your reply.  mips_classify_symbol never
> returns SYMBOL_GOTOFF_LOADGP.

Missed that bit.

> >> Under those circumstances, having separate symbol types for TLS symbols
> >> themselves just doesn't fit my mental model of how the MIPS code is
> >> supposed to work.  We always want to rewrite TLS symbols into "base +
> >> offset" form at rtl expansion time.  The rtl insns will always be
> >> operating on these offsets, not the original combined base+offset,
> >> so the new symbol types should also be attached to the offsets,
> >> not the original base+offset form.  That's why I suggested using
> >> symbol_types for each relocation type instead (which you agreed
> >> to try, thanks).
> >
> > Eh?  I don't think that's what I agreed to try at all.  I agreed to
> > replace the instruction I used patterns for with use of symbol relocs,
> > which seems like a definite winner.
> 
> By "that's why I suggested using symbol_types for each relocation type
> instead", I meant:
> 
> -------------------------------------------------------------------------
> 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("
> -------------------------------------------------------------------------
> 
> ...which I thought is what you'd agreed to.
> 
> Anyway, as far as the split_p thing goes, I'm afraid I'm not going to
> accept the patch unless you as least try doing it the way I suggested.
> Like I say, if you can show it's a bad idea for some (specific) reason,
> that's fine.  It's quite possible I'm wrong ;)  I just want to know
> _why_ I'm wrong.

I did try it the way you suggested, weeks ago.  I'm sorry I didn't save
it to show you.  I still have my notes from converting to mips_split_p,
but they don't offer a lot of details about the reverse transition.

Here's what happens: you still need to split a TLS SYMBOL_REF into high
and low parts somehow.  You need to do it in _exactly_ the same set of
places that mips_split_symbol is used.  You end up with duplicated code
corresponding to places where TLS symbols want to be handled as if
mips_symbolic_constant_p returned true.

Maybe I just did it wrong.

Hmm, I have an idea.  Let me try something and get back to you.

> > It's true that there are all of thirteen almost-identical lines in the
> > LD and GD cases.  Since it bothers you, I'll try for a helper next
> > time.  As I said, I consider the explicit straight-line code to be a
> > feature.
> 
> Hmm.  The difference between the GLOBAL_DYNAMIC and LOCAL_DYNAMIC was
> what?  The 2 get_tls_?d_[ds]i calls I mentioned?  I don't see how 13
> cut-&-paste lines of low-level rtl machinery is more readable than:
> 
>      case TLS_MODEL_GLOBAL_DYNAMIC:
>        mips_call_tls_get_addr (...gd...);
>        break;
> 
>      case TLS_MODEL_LOCAL_DYNAMIC:
>        mips_call_tls_get_addr (...ld...);
>        break;

The LD sequence contains, as a prefix, something that mostly resembles
the GD sequence except for the relocation operator used.  A pretty
short sequence.  Then there's a different equivalence value on the
libcall block, indicating that it is the LDM value, and as much again
additional code to add in the dtprel offset.

-- 
Daniel Jacobowitz
CodeSourcery, LLC