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]
Other format: [Raw text]

should MEM tracking be able to optimize this?



The following 2 functions should generate very similar assembly, right?

struct {
  float f[2048];
  float p[2048];
  float q[2048];
  float d[2048];
} A;


void
calc1 (void)
{
  int i;
  for (i = 0; i < 1024; ++i) {
    A.f[i]  = A.p[i] + A.q[i];
    A.d[i]  = A.p[i] + A.q[i]; 
    A.f[i]  = A.f[i] + A.p[i] + A.q[i];
  }
}

float f[2048];
float p[2048];
float q[2048];
float d[2048];

void
calc2 (void)
{
  int i;
  for (i = 0; i < 1024; ++i) {
    f[i]  = p[i] + q[i];
    d[i]  = p[i] + q[i]; 
    f[i]  = f[i] + p[i] + q[i];
  }
}


On sparc-sun-solaris2.8 using -O2 I get the following assembly:
(from a gcc updated about 1 hour ago when using -O2, just the loops
are shown)


calc1:
[snip]
.LL5:
	sll	%i5, 2, %i1	! i
	add	%i1, %o0, %i2
	add	%i1, %o7, %i3
	ld	[%i4+%i3], %f3	! A
	ld	[%i4+%i2], %f2	! A
	fadds	%f2, %f3, %f2
	st	%f2, [%i4+%i1]	! A
	ld	[%i4+%i3], %f2	! A
	ld	[%i4+%i2], %f3	! A
	fadds	%f3, %f2, %f3
	add	%i1, %g1, %i0
	st	%f3, [%i4+%i0]	! A
	ld	[%i4+%i2], %f4	! A
	ld	[%i4+%i1], %f2	! A
	ld	[%i4+%i3], %f3	! A
	fadds	%f2, %f4, %f2
	fadds	%f2, %f3, %f2
	add	%i5, 1, %i5	! i, i
	cmp	%i5, 1023	! i
	ble	.LL5
	st	%f2, [%i4+%i1]	! A
[snip]

calc2:
[snip]
.LL13:
	sll	%o2, 2, %o0	! i
	ld	[%o4+%o0], %f2	! p
	ld	[%o3+%o0], %f3	! q
	fadds	%f2, %f3, %f4
	fadds	%f4, %f2, %f2
	fadds	%f2, %f3, %f2
	add	%o2, 1, %o2	! i, i
	st	%f2, [%o5+%o0]	! f
	cmp	%o2, 1023	! i
	ble	.LL13
	st	%f4, [%o1+%o0]	! d



"calc1" one has too many loads and stores...  
Should MEM tracking be able to dissambiguate the non-dependend loads
and stores in "calc1"?




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