Re: PATCH: mips16 function attributes, version N+1

[Sandra Loosemore <sandra at codesourcery dot com>]

Richard Sandiford wrote:
> Sandra Loosemore <sandra@codesourcery.com> writes:
> > (2) tls/alias-1.c: Here we have a reference to a file-scope nomips16 tls 
> > variable inside a function compiled in mips16 mode.  It's breaking 
> > because tls is handled differently in the two modes.  I could reset 
> > targetm.have_tls when entering a function in the non-default mode, but 
> > when I looked at this before, I didn't see any test for tls support 
> > being made on *references* to tls variables, only on *declarations*.
>
> OK.  Do we get an ICE?  

It was failing with a link error, because the end-of-file goo emutls 
emits when the whole file is in mips16 mode wasn't happening when just 
one function was in mips16 mode.

> If so, does it work if you remove:
>
>   static int mips_base_have_tls;  /* targetm.have_tls */
>   ...
>     targetm.have_tls = mips_base_have_tls;
>   ...
>         /* We don't have a thread pointer access instruction on MIPS16, or
>            appropriate TLS relocations.  */
>         targetm.have_tls = false;
>   ...
>     mips_base_have_tls = targetm.have_tls;
>
> and simply put something like:
>
>   if (TARGET_MIPS16)
>     {
>       /* We don't have an instruction to access the thread pointer on MIPS16,
>          or appropriate TLS relocations.  */
>       sorry ("MIPS16 TLS);
>       return gen_reg_rtx (Pmode);
>     }
>
> in mips_legitimize_tls_address?  We don't want to use different TLS models
> (emulated vs. non-emulated) for MIPS16 and non-MIPS16 code.
>
> Unfortunately, this will probably mean a bit of testsuite work, since
> we've now removed dg-effective-target-tls (or whatever it was called).

I tried this, and yes, it does cause about half a dozen of the tls tests 
to fail with -mflip-mips16.  Rather than trying to mess with 
conditionalizing those, how about if I just leave the sorry message in, 
and document that this is one of the things that doesn't work yet?  In 
extend.texi I've already written:

  Mixed MIPS16 and non-MIPS16 code may interact badly with some GCC
  extensions such as @code{__builtin_apply} (@pxref{Constructing
  Calls}).

so I could just add:

  and thread-local variables (@pxref{Thread-Local}).

> The best long-term fix is of course to define TLS for MIPS16, but that's
> way down the line.  We don't even have _abicalls_ support for MIPS16 yet,
> never mind TLS.

Right.  I think this is really just another case where the failure isn't 
specific to -mflip-mips16.

-Sandra