Re: Move mips port to in_small_data_p

[Richard Sandiford <rsandifo at redhat dot com>]

Richard Sandiford <rsandifo@redhat.com> writes:
> +   else if (TARGET_MIPS16)
> +     {
> +       /* Alhough it seems strange to have separate rules for -mips16,
> + 	 this behaviour is long-standing.  */
> +       if (TREE_PUBLIC (decl)
> + 	  && (DECL_COMMON (decl)
> + 	      || DECL_ONE_ONLY (decl)
> + 	      || DECL_WEAK (decl)))
> + 	return false;
> +     }

After umming and ahhing about this, I think it was the wrong thing to do.

It's another case where select_section/unique_section differed from
encode_section_info.  The logic above came from encode_section_info:
select_section/unique_section treated mips16 code in the same way as 
non-mips16 code.

Moving this to in_small_data_p has changed the choice of section for
weak and linkonce symbols.  I.e. it's changed the ABI.

The change was first made here:

    http://gcc.gnu.org/ml/gcc-patches/2002-03/msg01089.html

and I'm guessing it was for the same sort of problem as:

    http://gcc.gnu.org/ml/gcc-patches/2002-05/msg01255.html

namely:

    [...] rtti.c lies to the backend, pretending that all typeinfo nodes
    have type type_info, which has sizeof==8.  So the mips-elf toolchain
    decides it can get to one with a gp-relative reloc.  Of course, the
    node for bad_exception is actually of a larger type.  And it is in a
    separate linkonce section.  Both of these cause the optimization to
    be wrong; the second is easier to use in a fix.  So now we check
    DECL_COMDAT in the mips backend.

Jason suggested reverting the second patch since the underlying problem
has been fixed:

    http://gcc.gnu.org/ml/gcc-patches/2002-08/msg01188.html

As I said in my original post:

    http://gcc.gnu.org/ml/gcc-patches/2003-07/msg00705.html

I deliberately did this as part of the in_small_sdata patch.  I think we
should the same for the mips16 hunk.

Doing this would be a little more far-reaching though.  Given -mips16 -G8,
gcc 3.[123] will not use gp-relative accesses for "x" in:

        int x;
        int f() { return x; }

since gcc treats "x" as a common symbol.  3.0 _would_ use gp-relative
accesses, and so would 3.4 if we revert the hunk above.

I guess this would be a user-visible change in the sense that the
3.[123] output could be linked with any -G option while the 3.0 output
had to be linked with -G8.  But we've never intentionally supported
linking -G8 code with -G0, so I'm not sure whether this matters much.

I believe that the choice of output section has remained the same for a
long time.  Barring any other ABI issues, it should still be possible to
link against old objects if we revert.

Tested on mips64vrel-elf.  OK to install?

Richard


	* config/mips/mips.c (mips_in_small_data_p): Don't handle
	TARGET_MIPS16 specially.

Index: config/mips/mips.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/config/mips/mips.c,v
retrieving revision 1.287
diff -c -d -p -F^\([(a-zA-Z0-9_]\|#define\) -r1.287 mips.c
*** config/mips/mips.c	8 Jul 2003 17:36:01 -0000	1.287
--- config/mips/mips.c	12 Jul 2003 13:00:49 -0000
*************** mips_in_small_data_p (decl)
*** 7876,7891 ****
        if (TREE_READONLY (decl)
  	  && !TREE_SIDE_EFFECTS (decl)
  	  && (!DECL_INITIAL (decl) || TREE_CONSTANT (DECL_INITIAL (decl))))
- 	return false;
-     }
-   else if (TARGET_MIPS16)
-     {
-       /* Alhough it seems strange to have separate rules for -mips16,
- 	 this behaviour is long-standing.  */
-       if (TREE_PUBLIC (decl)
- 	  && (DECL_COMMON (decl)
- 	      || DECL_ONE_ONLY (decl)
- 	      || DECL_WEAK (decl)))
  	return false;
      }
  
--- 7868,7873 ----