Re: mips 64-bit address generation is broken.

["Maciej W. Rozycki" <macro at ds2 dot pg dot gda dot pl>]

On 18 Feb 2002 cgd@broadcom.com wrote:

> >  Why?  An offsetted 32-bit address is 32-bit as well, so you don't want
> > 64-bit operations.  For a proper result you need to sign-extend low 32
> > bits of the 64-bit offset, though.
> 
> If you say 'dla' though, you want a 64-bit address.

 "dla" should probably be discouraged (or maybe even forbidden) for 32-bit
objects (see also my comments in
'http://sources.redhat.com/ml/binutils/2002-02/msg00532.html' and
follow-ups).  And similarly for "la" and 64-bit objects.

> The way I see this, the address size in the object format is something
> that you have to cope with, rather than something to be cherished.

 Of course -- you should be able to use both 64-bit and 32-bit addresses
in 64-bit objects (32-bit addresses merely mean operations to load high 32
bit may be skipped when expanding macros by tools if they decide to do
so).  And you should be able to use 32-bit addresses in 32-bit objects. 
Using 64-bit addresses in 32-bit objects should be disallowed as they
don't support them -- pretending it's otherwise would at least be
confusing to a user and may lead to unpredictable behavior.

> 	* 32-bit object-file address format and 'la'.  Easy enough: do
> 	32-bit load and subsequent operations as 32-bit.

 Obvious.

> 	* 64-bit object-file address format and 'la' or 'dla':
> 	64-bit load and subsequent operations as 64-bit.

 Ditto.

> 	* 32-bit object-file address format and 'dla'.  The result
> 	should be a 64-bit address.  you have to do a 32-bit load
> 	(sign-extending) from the object format, but then do
> 	subsequent ops as 64-bit operations.

 I would expect the result to be the same as from a "la" (well,
technically you may use 64-bit intermetiate operations, but there is no
need to, as the result has to be truncated anyway).  Strictly speaking,
I'm not sure why "dla" was introduced at all -- all MIPS processor
documentation only defines the "la" macro regardless of the register size
used in address calculation -- it's unambiguous for a given address size. 

> The complete example is:
> 
> /* Verify that the compiler uses 'dla' to load 64-bit addresses (leadi
>    pattern in mips.md).  */
> /* { dg-do run { target mips64*-*-elf } } */
> /* { dg-options "-O2 -mlong64" } */
> 
> extern void abort (void);
> extern void exit (int);
> 
> void pointer_test(void);
> extern void exit(int);
> 
> static char *p, *q;
> 
> 
> void pointer_test(void)
> {
> 
>   if ((unsigned long)p > (unsigned long)(q + 0x20000))
>     exit (1);
> }
> 
> int main(void)
> {
>   p = (char *) 0x0000000100000000UL;
>   q = p;
> 
>   pointer_test();
>   exit (0);
> }
> 
> 
> Then see the original pointer_test disassembly that you get with 'dla'
> if you do a 32-bit add, and you'll see why that loses.

 There are two possibilities for the code for pointer_test (base on your
gcc-emitted source): 

1. For a 32-bit address width:

lw      $2,q
lw      $3,p
la      $2,131072($2)
sltu    $2,$2,$3

where the "la" expands to:

lui     $1,0x2
addu    $2,$1

2. For a 64-bit address width:

ld      $2,q
ld      $3,p
dla     $2,131072($2)
sltu    $2,$2,$3

where the "dla" expands to:

lui     $1,0x2
daddu   $2,$1

 I fail to see any other possibilities for regular code.  For weird
hand-coded assembly you may of course use whatever you want, but I don't
see any reason to twiddle with builtin macros for this purpose -- you may
code necessary bits explicitly.  Offsetting variables on a 32-bit stack by
64-bit values doesn't qualify as regular code, IMO, and I can't imagine
anyone to disagree here.  If gcc generates such code, it needs to be
fixed. 

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +