This is the mail archive of the mailing list for the binutils 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]

[PATCH RFA] MIPS 64-bit-addressing load/store macro addr genopt.

The patch below optimizes load/store macro address generation when
compiling for 64-bit addresses and generating a 32-bit constant


        lw     $2,-2147483648

which is what you get when you ask "mips-elf-gcc -membedded-pic" (gcc
3.0.3 + some mods which don't impact this) to compile:

foo() {
        *(volatile int *)0x80000000;

The current binutils will turn that macro into a fairly long (6 or 7)
instruction sequence, when all that's really necessary for constant
sign-extended 32-bit address generation is (at most) two instructions

   c:   3c028000        lui     v0,0x8000
  10:   8c420000        lw      v0,0(v0)

AFAIK, right now the only 'real use' of the 64-bit address code is for
-membedded-pic.  Are people actually trying to run "64-bit address"
(i.e., abi=64) through the in-tree assembler sources yet?  Anyway, so,
right now this should only affect -membedded-pic compilation, but when
abi=64 becomes the norm it makes that better too.

I've been running this in my source tree here (binutils based on
current sources as of 2002-01-31) using it fairly heavily for
-membedded-pic for a few days.  Also, i've verified that w/ this patch
current binutils runs "gmake && gmake check" (targets mips-elf,
mips64-elf, mips-linux; host x86-linux) w/ no failures.

(Note that in the diff below, the use of the new macro in
load_register looks like it has the wrong indentation or is
parenthesized wrong.  That's an artifact of tabs vs. spaces in the

2002-02-08  Chris Demetriou  <>

	* config/tc-mips.c (IS_SEXT_32BIT_NUM): New macro to
	determine if a number is a sign-extended 32-bit number.
	(load_register): Use IS_SEXT_32BIT_NUM.
	(macro): Check if load/store macro handling is using a
	constant 32-bit address on 64-bit address systems, and if
	so optimize the generation of that address.

Index: config/tc-mips.c
RCS file: /cvs/src/src/gas/config/tc-mips.c,v
retrieving revision 1.106
diff -u -p -r1.106 tc-mips.c
--- tc-mips.c	2002/01/30 02:14:19	1.106
+++ tc-mips.c	2002/02/08 20:09:46
@@ -3353,6 +3353,11 @@ check_absolute_expr (ip, ex)
            ? 1                          \
            : 0)
+/* Is the given value a sign-extended 32-bit value?  */
+#define IS_SEXT_32BIT_VAL(x)						\
+  (((x) &~ (offsetT) 0x7fffffff) == 0					\
+   || (((x) &~ (offsetT) 0x7fffffff) == ~ (offsetT) 0x7fffffff))
 /*			load_register()
  *  This routine generates the least number of instructions neccessary to load
  *  an absolute expression value into a register.
@@ -3392,9 +3397,7 @@ load_register (counter, reg, ep, dbl)
 		       (int) BFD_RELOC_LO16);
-      else if ((((ep->X_add_number &~ (offsetT) 0x7fffffff) == 0
-		 || ((ep->X_add_number &~ (offsetT) 0x7fffffff)
-		     == ~ (offsetT) 0x7fffffff))
+      else if ((IS_SEXT_32BIT_VAL(ep->X_add_number)
 		&& (! dbl
 		    || ! ep->X_unsigned
 		    || sizeof (ep->X_add_number) > 4
@@ -5544,8 +5547,17 @@ macro (ip)
 	       dsll	$tempreg,16
 	       daddu	$tempreg,$tempreg,$breg
 	       <op>	$treg,<sym>($tempreg)	(BFD_RELOC_LO16)
+	     If we have 64-bit addresses, as an optimization, for
+	     addresses which are 32-bit constants (e.g. kseg0/kseg1
+	     addresses) we fall back to the 32-bit address generation
+	     mechanism since it is more efficient.  This code should
+	     probably attempt to generate 64-bit constants more
+	     efficiently in general.
+	      && !(offset_expr.X_op == O_constant
+		   && IS_SEXT_32BIT_VAL(offset_expr.X_add_number)))
 	      p = NULL;

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