This is the mail archive of the gcc@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]

reg+reg addressing mode on SPARC


Hi!

GCC seems to be using the reg+reg addressing mode quite a lot, even 
when it's not a clear win. 

For example the following:

int  y[1024];

int
main()
{
  
  register int    k;
  int z;
  
  for (k = 0; k < 1024; k++){
    z += y[k];
  }

  return z;
}

is compiled by gcc-3.0 -O2 to: 
(just the loop is shown)

.LL5:
	sll	%o2, 2, %o0
	ld	[%o4+%o0], %o1
	add	%o2, 1, %o2
	cmp	%o2, 1023
	ble	.LL5
	add	%o3, %o1, %o3
	retl
	mov	%o3, %o0


int  y[1024];

int
main()
{
  
  register int    k;
  int z;
  int *x = y;
  
  for (k = 0; k < 1024; k++ , x++ ){
    z += *x;
  }

  return z;
}

is compiled by gcc-3.0 -O2 to: 
(just the loop is shown)

.LL5:
	ld	[%o3], %o0
	addcc	%o1, -1, %o1
	add	%o2, %o0, %o2
	bpos	.LL5
	add	%o3, 4, %o3
	retl
	mov	%o2, %o0

ie an extra instruction in the loop in the first case.

Now look at the assembly generated for both when using 
-O2 -funroll-all-loops 
For the first case: 
[snip]
        sll     %i0, 2, %i0
        ld      [%o0+%i0], %i3
        add     %o7, 2, %i1
        sll     %i1, 2, %i1
        ld      [%o0+%i1], %i4
        add     %o7, 3, %i0
        add     %g1, %i2, %g1
        sll     %i0, 2, %i0
[snip]
so for each load there are an sll and 2 adds

the second case:
[snip]
        ld      [%o4+4], %o1
        add     %o3, %o0, %o3
        ld      [%o4+8], %o2
        add     %o3, %o1, %o3
[snip]
only one add for each load. 

It gets very messy in the first case due to using too many
registers...

The Sun 5.0 compiler does not use reg+reg addressing in any of those 2
examples. (and in a lot of other code that I looked at)

I have no idea if the above 2 examples are representative enough, or
if there is anything to win from not using reg+reg addressing modes...

Does anybody know if looking into not using reg+reg addressing modes
would be worthwhile? 
If yes is ADDRESS_COST the macro that needs to be changed? 

Thanks.
        --dan


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