Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!wuarchive!psuvax1!rutgers!cmcl2!lanl!cochiti.lanl.gov!jlg
From: jlg@cochiti.lanl.gov (Jim Giles)
Newsgroups: comp.lang.c
Subject: Re: low level optimization
Message-ID: <21660@lanl.gov>
Date: 17 Apr 91 16:43:37 GMT
References: <andand.671719926@cia.docs.uu.se> <15828@smoke.brl.mil> <21527@lanl.gov> <15870@smoke.brl.mil>
Sender: news@lanl.gov
Organization: Los Alamos National Laboratory
Lines: 56

In article <15870@smoke.brl.mil>, gwyn@smoke.brl.mil (Doug Gwyn) writes:
|> In article <21527@lanl.gov> jlg@cochiti.lanl.gov (Jim Giles) writes:
|> [...]                                        C must assume that all
|> >pointers are possibly aliased ...  There is not a single significant
|> >optimization technique that is not inhibited to some extent or other
|> >by aliasing.
|> 
|> The latter is a gross overgeneralization, and in any event the
|> assertion is simply not true.  There are SOME circumstances under
|> which aliasing must be assumed to be possible, but by no means ALL
|> circumstances.

All array arguments to a procedure must be assumed aliased to each
other and to any globals of the same base type.  Indeed, due to the
fact that most C programmers violate the rules prohibiting type casts
of pointers to different types, all arrays should be assumed aliased
to globals and other pointers of _any_ type.  Any locally declared
pointers which are assigned to the any of the above (pointer args,
and/or the addresses of globals) must also be assumed aliased to
these things.

|> [...]
|> I wasn't particularly referring to array-intensive applications
|> anyway, because most interesting "scientific" applications that
|> I have encountered require more flexibility than the use of fixed
|> arrays provides.  Each language should be dealt with on its own
|> terms, not treated as an inferior substitute for one's favorite
|> language.

Then you shouldn't make unqualified statements that are not true.
Your claim was that C was inherently as fast or faster than Fortran
for all operations (you made the exception of _old_ C implementations
that forced double computation instead of float).  To now say that you
weren't including array-intensive applications is a little late.

Most of the array calculations I have encountered require more 
flexibility than pointers provide - like the flexibility to declare
two things _not_ to be aliased.

|> [...]
|> >I've never seen a purely standard conforming C compiler
|> >that can come close to Fortran.
|> 
|> Well, I have.


Really?  I'm sitting on the edge of my chair.  Where can I learn more
about this paragon?  It must use compilation techniques that are not
described in any of the existing literature since I have seen verified
to my satisfaction that 1) aliasing _does_ inhibit _all_ major optimization
techniques, and 2) most uses of C pointers are either aliased in truth,
or are not distinguishable (by the compiler) from aliased ones.  The only
way around this difficulty is interprocedural analysis - but C requires
separate compilation. 

J. Giles