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

[Richard Sandiford <richard at codesourcery dot com>]

Sandra Loosemore <sandra@codesourcery.com> writes:
> (1) built-in-setjmp.c: This also fails if the two functions are compiled 
> in separate files, so it's a problem with mixed-mode operation 
> generally, not the mode-switching code.

Yeah, I think you can ignore this for now.  The problem is that the
setjmp and longjmp calls disagree on whether $17 or $31 is the frame
pointer.  I suppose one fix would be to make the MIPS16 versions of
setjmp and longjmp pass the frame pointer in $31 rather than $17,
but it would mean an ABI change.

As you suggest, this is a pre-existing bug that isn't directly to the
attributes.  The attributes actually give the user a way around the
problem that they didn't have previously.

> (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?  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).

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.

Richard