🚀 go-pugleaf

> The released version of gcc2 doesn't seem to do a very good job of scheduling
> compared to the sun compiler that comes with sunos (4.1.1).
...
> float dotprod(vec1,vec2,length)
> float *vec1, *vec2;
> int length;
> {
>     int i;
>     float sum=0;
>
>     for(i=0; i<length; i++)
> 	sum+=vec1[i]*vec2[i];
>
>     return sum;
> }
>
...
> 
> "gcc2 -O2 -funroll-loops"	"cc -O4 -fsingle"
>
> L5:				L77003:
> 	ld [%o0],%f2		        ld      [%o0],%f1
> 	ld [%o1],%f1		        ld      [%o5],%f2
> 	fmuls %f2,%f1,%f1	        fmuls   %f1,%f2,%f1
> 	fadds %f0,%f1,%f0	        ld      [%o0+4],%f4
> 	ld [%o0+4],%f2		        fadds   %f30,%f1,%f30
> 	ld [%o1+4],%f1		        ld      [%o5+4],%f5      
> 	fmuls %f2,%f1,%f1	        fmuls   %f4,%f5,%f4
> 	fadds %f0,%f1,%f0	        fadds   %f30,%f4,%f30
> 	ld [%o0+8],%f2		        ld      [%o0+8],%f7
> 	ld [%o1+8],%f1		        ld      [%o5+8],%f8
> 	fmuls %f2,%f1,%f1	        fmuls   %f7,%f8,%f7
> 	fadds %f0,%f1,%f0	        ld      [%o0+12],%f10
> 	ld [%o0+12],%f2		        fadds   %f30,%f7,%f30
> 	ld [%o1+12],%f1		        ld      [%o5+12],%f11
> 	fmuls %f2,%f1,%f1	        fmuls   %f10,%f11,%f10
> 	add %g2,16,%g2		        inc     16,%o5
> 	cmp %g2,%o3		        add     %o5,12,%g2
> 	add %o0,16,%o0		        fadds   %f30,%f10,%f30
> 	add %o1,16,%o1		        cmp     %g2,%o1
> 	bl L5			        blu     L77003
> 	fadds %f0,%f1,%f0	        inc     16,%o0

Instruction scheduling is not the problem.  Indeed GCC seems to be
doing this better than Sun C - note how the final "fadds" has been
pushed past the compare and branch instructions, all the way to the
very end of the loop in GCC.

The problem is with loop unrolling.  The (psuedo) registers allocated
for vec1[i], vec2[i], and sum are not split for each unrolled copy of
the loop.  This severely limits the opportunities for instruction
scheduling which is performed subsequently.

GCC currently only splits - during loop unrolling - those registers
which represent induction variables ie. values of the form const1 +
iteration_count * const2.

It would probably be relatively straight forward to modify the
compiler to split the registers holding vec1[i] and vec2[i] - much as
the Sun compiler appears to do.  Although splitting sum would be more
difficult since its value is used outside the loop - the Sun compiler
does not appear to attempt this.

I suspect that since the GNU backend is currently only used for C et
al., whereas Sun's backend is also used for Fortran, that the GNU
backend has not been tuned for performance on floating point array
intensive code to the same extent as the Sun compilers.  For integer
code the gains brought about by splitting non-induction loop variables
would be relatively modest, indeed almost non-existent, on account of
only load instructions ever stalling.

For many C programs in the absence of any execution time feedback it
is quite likely that loop unrolling will actually slow a program down
because of the increased number of cache misses.  This probably
currently diminishes the incentive to spend time developing code to
split non-induction variables during loop unrolling.

Roll on GNU Fortran.

                                                 Gordon Irlam.