RFA: MIPS TLS support

[Richard Sandiford]

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.

>> 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.

>> 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.

As I say, your current implementation just doesn't match my mental model
of how the MIPS code is supposed to work.  If you don't understand
_what_ it is I'm asking you do, please shout, and I'll try to explain
it better.  If you don't understand _why_, well, can't you just agree
to disagree? ;)

>> No, I meant that the LOCAL_* and GLOBAL_* cases seemed to be cut-&-paste
>> copies of one another with s/tls_ld/tls_gd/.  With your old set-up,
>> it would have been easy to have a helper function that emits a call to
>> __tls_get_addr() and pass the appropriate gen_tls_?d_di and gen_tls_?i_si
>> functions to it.  With the new symbol types, you should just be able to
>> pass the symbol type instead.
>
> 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;

(BTW, in case you're wondering, I don't mind reviewing patches that
have only been lightly tested.  There doesn't seem to be much point
doing a full glibc build, bootstrap, etc., for each revision until
we've got some agreement on how the code should work in principle.)

Richard