mips 64-bit address generation is broken.

[cgd at broadcom dot com]

I'm again coming to think that mips 64-bit address generation is Just
Broken in the current binutils.

Consider a mips64-elf toolchain, compiling the code:

	static char *p, *q;
	
	void pointer_test(void)
	{
	
	  if ((unsigned long)p > (unsigned long)(q + 0x20000))
	    exit (1);
	}

For this, mips64-elf-gcc -mlong64 -O2 will emit code like:

	pointer_test:
	        .frame  $sp,40,$31              # vars= 0, regs= 1/0, args= 32, extra= 0
	        .mask   0x80000000,-8
	        .fmask  0x00000000,0
	        ld      $2,q
	        ld      $3,p
	        dsubu   $sp,$sp,40
	        dla $2,131072($2)               # leadi
	        sltu    $2,$2,$3
		[ ... ]

(actually, that's not quite true: right now it will emit code that
does 'la' instead of 'dla' -- but that's broken, right?  to load a
64-bit address, it should be using dla, right?  So, I fixed that, and
was going to submit the fix to gcc with a test case, but the test case
still doesn't work because of binutils issues...

It doesn't work because that gets assembled into:

	00000000 <pointer_test>:
	   0:   df82c008        ld      v0,-16376(gp)
	                        0: R_MIPS_GPREL16       .sbss+0x4000
	   4:   df83c000        ld      v1,-16384(gp)
	                        4: R_MIPS_GPREL16       .sbss+0x4000
	   8:   67bdffd8        daddiu  sp,sp,-40
	   c:   3c010002        lui     at,0x2
	  10:   00221021        addu    v0,at,v0
	  14:   0043102b        sltu    v0,v0,v1
	  [ ... ]

Looks like what's going on is that the code is using the
object-file-format-based 32-bit address determination to decide
whether to use 'addu' or 'daddu' to do the final add when calculating
the result.

While that's probably the right thing for 'la' in a 32-bit address
environment, or when 64-bit GPRs aren't available it doesn't seem to
be the right thing if using 'dla' like the above, even if your object
formats have only 32-bit addresses.  (otherwise, what's the real diff
between dla and la?)


Any thoughts on this?

I've not gone through and actually tested a change to do this yet...
but i'll need to do so soon.


(*sigh*  The breakage caused by the HAVE_32BIT_ADDRESSES changes has
... really caused us a fair bit of pain.  I can only imagine what
it'll do to other random users who only use binutils releases, after
2.12 is released...)



cgd