This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

mips tls with -mlong64/-mgp32


If TLS pointers are 64 bits but GP registers are 32 bits, the TLS load
needs to be split.  This means we need to support offsetted GOT
addresses, at least for TLS (perhaps for more, but this is the only
one that causes a failure in the testsuite - gcc.dg/tls/nonpic.c)

This results in code like this, which the assembler seems to be ok
with:

        lw      $3,%tprel_lo(e1+4)($2)
        lw      $2,%tprel_lo(e1)($2)

This is similar to the change I made to s390 last October.  Only
lightly tested (else you'd have to wait a week or so for dg results).
Ok?  Should other symbols be similarly offsettable?

	* config/mips/mips.c (mips_symbolic_constant_p): Allow TPREL
	offset-by-4 so we can split DImode GOT loads.

Index: mips.c
===================================================================
--- mips.c	(revision 124522)
+++ mips.c	(working copy)
@@ -1413,20 +1413,23 @@ mips_symbolic_constant_p (rtx x, enum mi
 	 address, and we will apply a 16-bit offset after loading it.
 	 If the symbol is local, the linker should provide enough local
 	 GOT entries for a 16-bit offset, but larger offsets may lead
 	 to GOT overflow.  */
       return SMALL_INT (offset);
 
+    case SYMBOL_TPREL:
+      if (GET_CODE (offset) == CONST_INT
+	  && INTVAL (offset) == 4)
+	return true;
     case SYMBOL_GOT_DISP:
     case SYMBOL_GOTOFF_DISP:
     case SYMBOL_GOTOFF_CALL:
     case SYMBOL_GOTOFF_LOADGP:
     case SYMBOL_TLSGD:
     case SYMBOL_TLSLDM:
     case SYMBOL_DTPREL:
-    case SYMBOL_TPREL:
     case SYMBOL_GOTTPREL:
     case SYMBOL_TLS:
     case SYMBOL_HALF:
       return false;
     }
   gcc_unreachable ();


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]