low level optimization
Jim Giles
jlg at cochiti.lanl.gov
Thu Apr 18 02:43:37 AEST 1991
In article <15870 at smoke.brl.mil>, gwyn at smoke.brl.mil (Doug Gwyn) writes:
|> In article <21527 at lanl.gov> jlg at 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
More information about the Comp.lang.c
mailing list