Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!emory!gatech!purdue!haven!ncifcrf!lhc!adm!smoke!gwyn
From: gwyn@smoke.brl.mil (Doug Gwyn)
Newsgroups: comp.lang.c
Subject: Re: low level optimization
Message-ID: <15903@smoke.brl.mil>
Date: 20 Apr 91 19:31:18 GMT
References: <1991Apr18.233807.19552@zoo.toronto.edu> <21868@lanl.gov> <3906@inews.intel.com>
Organization: U.S. Army Ballistic Research Laboratory, APG, MD.
Lines: 22

In article <3906@inews.intel.com> bhoughto@bishop.intel.com (Blair P. Houghton) writes:
>You're so hyped up about the fact that separate compilation
>prevents use of this optimization, but you haven't been
>so vocal about the case where you deliberately alias one
>of your arrays, which also blows your optimization.

Which is one reason why this is not a C-specific issue.
The fact that the Fortran standard prohibits a program from
calling subroutines with arguments that are overlapping array
sections, thereby enabling a certain class of optimizations
(loop vectorization), means that a class of useful program
constructs are also outlawed.  Any reasonable language that
supports pointer arguments needs to deal with this issue one
way or another; Fortran came down on the side of restricting
the programmer, while C came down on the side of empowering
the programmer.  Due to these stupid "Fortran vs. C" arguments,
C implementors have looked very hard at ways to perform
Fortran-like optimizations for C pointer parameter usage, and
have devised a number of techniques for enabling the
optimization in many circumstances.  Cray's Standard C
Compiler release 2.0 is an example of a C compiler that
performs extensive optimization, including loop vectorization.