Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!cmcl2!kramden.acf.nyu.edu!brnstnd
From: brnstnd@kramden.acf.nyu.edu (Dan Bernstein)
Newsgroups: comp.lang.c
Subject: Re: low level optimization
Message-ID: <11385:Apr2702:37:4891@kramden.acf.nyu.edu>
Date: 27 Apr 91 02:37:48 GMT
References: <RJC.91Apr20023816@brodie.cstr.ed.ac.uk> <22355@lanl.gov> <RJC.91Apr25134502@brodie.cstr.ed.ac.uk>
Organization: IR
Lines: 26

In article <RJC.91Apr25134502@brodie.cstr.ed.ac.uk> rjc@cstr.ed.ac.uk (Richard Caley) writes:
  [ quite reasonable suggestions ]

Gee, sounds like exactly the same argument as we had in comp.lang.misc.
Jim said that because C *allows* aliasing, it *forces* optimizers to
assume aliasing at every step. I said that the compiler could put
together any number of versions of each subroutine, one for each set of
anti-aliasing constraints chosen by any fixed algorithm.

It could, for instance, compile one version where no arguments are
aliased, and one where all arguments are aliased. In the case Jim cares
about (i.e., Fortran-ish array code), nothing would be aliased, so the
optimized versions would be used in every case. So the C code would be
optimized *exactly* as well as a Fortran version, with *no*
interprocedural analysis on the linker's part.

How quickly Jim forgets.

Well, no, I should be fair: he never admitted to losing the argument
that time, so he probably doesn't realize that he's lost it this time.
Poor guy. Still, Caley and I came up with the solution independently,
and probably any compiler writer who doesn't have such a closed mind as
Jim can come up with it too, so I don't think Jim's prejudice will hurt
the future of C optimization.

---Dan