GCC for Mac OS X

[Jeffrey A Law]

  In message < 38A898F6.3BFDCF16@moene.indiv.nluug.nl >you write:
  > Stan Shebs wrote:
  > 
  > > I wrote:
  > 
  > > > us physicists are very much interested in
  > > > a g77 generating vector arithmetic on a home computer (or even a laptop
  > > > - if Apple ever manages to put a G4 in a PowerBook ;-)
  > 
  > > In between doing email, I'm studying the patch.  It seems to involve a
  > > number of source language extensions, which is the part that seems
  > > especially difficult to justify for GCC.  On the other hand, the
  > > extensions have already been adopted by other G4 compilers, so GCC may
  > > want to do that just to keep up.  More as I find it out...
  > 
  > Hmmm, do I read correctly, between the lines, here that generating
  > vector code is dependent on support by frontends - bummer, that would
  > mean that the following obvious Fortran candidate code isn't improved at
  > all:
  > 
  >       subroutine saxpy(x,a,y,n)
  >       dimension x(n), y(n)
  >       do i = 1, n
  >          y(i) = y(i) + a * x(i)
  >       enddo
  >       end
  > 
  > ?
  > 
  > [ I hope the answer is no ;-) ]
An FYI -- conceptually what the Cygnus team has been looking at (from a high
level) is to hand off a loop (or nest of loops) to expand_expr with some
sort of annotation about loop carried dependencies (none, or every X
iterations).

expand_expr would be responsible for trying different code generation
strategies for vectorizing a loop (or rearranging for cache behavior).

We'd still have the entire loop at a tree level -- which makes it easier to
make sure variables are suitably aligned, coalesce loads/stores in an
appropriate manner, etc.

Pretending we have a loop with no carried dependencies and the backend
has support for 4-way SIMD we'd try to generate RTL for something like

load inputs for 4 operations
4-way SIMD operations
store outputs for the 4 operations

We'd then try to recognize the loop body -- if it succeeds, we twiddle the
test which controls the number of iterations and emit the vectorized loop.

Else we back off and try 2-way SIMD, then a normal serial loop.


That fits in reasonably well with GCC's existing tree->RTL conversion
phase.  It also provides what we *think* is the right place to do a
number of loop transformations (except fusion of disjoint loops).


One of the other thoughts we've kicked around is to generate multiple
versions of loop (similar that what Cygnus is doing for tail call opts)
and defer selection of a particular implementation of the loop until
a later point in the compiler.  It's a relatively complex solution, but
it has some nice properties -- like the potential ability to select an
implementation of the loop based on register pressure or other factors.

If someone wants to experiment with this, probably the place to start is
the C++ or java front-ends since they should be representing a loop as a
series of linked tree nodes wrapped in a LOOP_EXPR which is hopefully
passed to expand_expr.  Start by ignoring the loop carried dependency
problem and concentrate more on how to generate code -- it is expected
that much of the loop dependency analysis will drop out of the software
pipelining work Cygnus is currently doing.

jeff