Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!yale!cmcl2!kramden.acf.nyu.edu!brnstnd
From: brnstnd@kramden.acf.nyu.edu (Dan Bernstein)
Newsgroups: comp.lang.misc
Subject: Re: Answers, Chapter 2: to point or not to point
Message-ID: <24487:Nov906:17:2490@kramden.acf.nyu.edu>
Date: 9 Nov 90 06:17:24 GMT
References: <6243:Nov720:29:4090@kramden.acf.nyu.edu> <5220@lanl.gov>
Organization: IR
Lines: 51

In article <5220@lanl.gov> jlg@lanl.gov (Jim Giles) writes:
> From article <6243:Nov720:29:4090@kramden.acf.nyu.edu>, by brnstnd@kramden.acf.nyu.edu (Dan Bernstein):
> > In article <5088@lanl.gov> jlg@lanl.gov (Jim Giles) writes:
> > [...]
> >>    Modula 2                     C
> >>       for i := 1 to N do           p = &x[1][0]; q = p+N;
> >> 	 x[1,i] := x[2,i]          for (i=0; i<N; i++)
> >>       end;                            *p++ = *q++;
> > [...]
> > I believe that if you stated it correctly, the Convex compiler would be
> > able to optimize it (specifically, vectorize it) the way you want.
> I never claimed that a smart compiler _couldn't_ optimize the above.

Fine. Glad we settled that.

> I gave it originally as an example of something which the compiler
> would have to do _extra_ work to recover information

In this case, the compiler does little more than reverse that
preprocessing. Hardly a lot of work.

> if the array
> code were preprocessed into pointers (which you _did_ suggest should
> be done).

Did I really? Where? I certainly don't believe that all array code
should be converted into pointer code.

> With your stand against optimizers though, why do you claim that it's
> acceptable to put the compiler through all that extra work?

There are ranges of acceptability. Given that there isn't any simple
alternative, and given that putting i back is so trivial to do
correctly, I'm not going to argue against this optimization.

What I'd love to have is an automated tool that takes a section of code
and a new variable from me (like ``double *p = &x[1][i]'') and adds that
variable in, keeping track of changes to i at each step. Also a tool
that reduces the code by eliminating an unused variable (like ``i'').
Note that the original code is kept around for maintenance; perhaps make
or some other tool could ensure consistency. If the optimizer's
elementary (array reference) strength reduction were adapted to use this
mechanism, programming would be great. If I could then get a symbolic
algebra source-code peephole optimizer that understood how to keep track
of ``x * exp(y - 3 * z)'' as z changes, programming would be absolutely
amazing. If it understood range constraints and optimized using them,
splitting code into sections to make convenient constraints come true in
one section, I'd almost believe that automatic optimization could
compete with hand optimization.

---Dan