About my GO_IF_LEGITIMATE_ADDRESS change

[Wei Hu]

Hi,

Since you didn't follow up on my comment about the change, I didn't
post another piece of code. The ggx_print_operand_address function
must be expanded too:

switch (GET_CODE (x))
{
...
case PLUS:
op1 = XEXP(x,0);
op2 = XEXP(x,1);
if(GET_CODE(op1) == CONST_INT
&& (GET_CODE(op2) == REG))
fprintf(file,"%ld(%s)", INTVAL(op1), reg_names[REGNO(op2)]);
else if (GET_CODE(op2) == CONST_INT
&& (GET_CODE(op1) == REG ))
fprintf(file,"%ld(%s)", INTVAL(op2), reg_names[REGNO(op1)]);
else
LOSE_AND_RETURN ("Don't know how to print this address", x);
break;
...

[Wei Hu]

I once was surprised at the following code generated by gcc:
ldi.l $r1, -12
add.l $r1, $r1, $fp
sto.l -4($r1), $r0
I thought a single instruction sto.l -16($fp), $r0 would be enough.
This was after I applied my changes.

[gr...@spindazzle.org]

>
> Hi,
>
> Since you didn't follow up on my comment about the change, I didn't
> post another piece of code. The ggx_print_operand_address function
> must be expanded too:

Yes, I added this code myself once I applied your patch. The problem I
see is that reg+offset is now recognized as a memory operand anywhere we
ask for a memory operand in the machine description. When I applied
these two changes I would get output like:

sta.l -16($fp), 2

...which is clearly wrong.

Were you able to build libgcc with these changes? I wasn't.

[gr...@spindazzle.org]

>
> I once was surprised at the following code generated by gcc:
> ldi.l $r1, -12
> add.l $r1, $r1, $fp
> sto.l -4($r1), $r0
> I thought a single instruction sto.l -16($fp), $r0 would be enough.
> This was after I applied my changes.

Is $r1 used again after the sto.l? That might explain it.

AG

[Wei Hu]

You're right. I forgot that I also changed ggx.md.
I defined a new constraint:

(define_constraint "A"
"An absolute address."
(and (match_code "mem")
(match_test "GET_CODE (XEXP (op, 0)) == SYMBOL_REF
||GET_CODE (XEXP (op, 0)) == LABEL_REF
||GET_CODE (XEXP (op, 0)) == CONST")))

And then, I changed the constraints in "*movsi" from

(define_insn "*movsi"
[(set (match_operand:SI 0 "general_operand" "=r,r,W,m,r,r")
(match_operand:SI 1 "ggx_general_movsrc_operand"
"r,i,r,r,W,m"))]

to

(define_insn "*movsi"
[(set (match_operand:SI 0 "general_operand" "=r,=r,W,A,=r,=r")
(match_operand:SI 1 "ggx_general_movsrc_operand"
"r,i,r,r,W,A"))]

> >     ...- Hide quoted text -
>
> - Show quoted text -

[Wei Hu]

On May 5, 8:51 am, gr...@spindazzle.org wrote:
> > I once was surprised at the following code generated by gcc:
> >         ldi.l  $r1, -12
> >         add.l  $r1, $r1, $fp
> >         sto.l  -4($r1), $r0
> > I thought a single instruction sto.l -16($fp), $r0 would be enough.
> > This was after I applied my changes.
>
> Is $r1 used again after the sto.l?  That might explain it.

No. $r1 is immediately loaded with a constant.

wh5a@flitwick:/toolchain/gcc-4.3.0/gcc-4.3.0/tests$ cat 9.c
#include <stdio.h>

int foo(int a, int b) {
int mul(int x) {return a*x;}
return mul(a) + mul(b);
// bar(zero);
}

int main() {
printf("%d\n",foo (1, 2));
return(foo(1,2));
}

wh5a@flitwick:/toolchain/gcc-4.3.0/gcc-4.3.0/tests$ ggx-elf-gcc -O -S
9.c

wh5a@flitwick:/toolchain/gcc-4.3.0/gcc-4.3.0/tests$ less 9.s
...
foo:
push $sp, $r2
push $sp, $r3
push $sp, $r4
ldi.l $r5, -8
add.l $sp, $sp, $r5
sto.l -20($fp), $r1

ldi.l $r1, -12
add.l $r1, $r1, $fp
sto.l -4($r1), $r0

ldi.l $r1, -16
add.l $r2, $fp, $r1
...