🚀 go-pugleaf

In article <7300002@ux1.cso.uiuc.edu> hirchert@ux1.cso.uiuc.edu writes:

>brnstnd@stealth.acf.nyu.edu writes:
>>The only problem with aliasing is parallel optimization.

>Not true.  There are many sequential, scalar optimizations that are inhibited
>by aliasing, including common subexpression elimination, removal of loop
>invariants, strength reduction, and some forms of peephole instruction
>scheduling.  In fact, there are few forms of optimization that aren't
>inhibited by aliasing.

Good man!  An easy example is (everybody's favorite) DAXPY, the main time
consumer in Linpack.

      subroutine daxpy(n, da, dx, incx, dy, incy)
	...
        do 10 i = 1, n
          dy(iy) = dy(iy) + da * dx(ix)
          ix = ix + incx
          iy = iy + incy
10      continue
        return
	...
     end

If aliasing is prohibited, we can hold da, incx, and incy in registers.
Otherwise, they must be reloaded on each iteration, since the assignment
to dy(iy) could potentially change them all.

In one (experimental) compiler, the no-aliasing restriction saved us
fifteen percent.  On a machine with faster floating-point, the savings
would be greater.

Without the restriction, you need to do interprocedural alias analysis.
For languages without pointers, this can be done efficiently.
For C, with fairly unrestricted pointer usage, the problem is much harder.

Preston Briggs
preston@titan.rice.edu