low level optimization

Barry Margolin barmar at think.com
Fri Apr 19 05:04:03 AEST 1991


In article <21812 at lanl.gov> jlg at cochiti.lanl.gov (Jim Giles) writes:
>In article <1991Apr17.225944.15261 at zoo.toronto.edu>, henry at zoo.toronto.edu (Henry Spencer) writes:
>|> [...]                                           You do interprocedural
>|> analysis across all source files supplied to a single invocation of the
>|> compiler,  [...]
>
>And, if you subsequently change _some_ of those source files?  What 
>then?  Under this model, you'd have to recompile _all_ the others 
>that were originally compiled together.  This violates one of the 
>principle reasons to have separate compilation to begin with - the 
>elimination of the needto recompile most of your code every time 
>you change a piece of it.

When one is in a heavy edit-compile-test loop, one normally disables many
of the optimizations that slow down the compile step.  So, during this
stage of development you probably wouldn't use the inter-module analysis
option, and would only have to recompile the modules that you edited.

When you get to the stage of compiling with all the optimization options,
then you might have to recompile lots of files each time you change just
one.  Hopefully, by this time in the development such changes should be
rare.

>  I'm just pointing out that it _does_ violate the
>standards of both Fortran and C which are defined to be separately
>compiled.  There are a lot of _non-standard_ ways to improve
>performance.  But, it is always a mistake to allow someone to 
>claim that any of these are really standard after all.`

I interpreted the section of the standard that you quoted in another
posting as *allowing* separate compilation.  This means that the programmer
isn't forced to compile everything together in order to achieve the
semantics specified by the language.  However, this doesn't prohibit an
implementation from providing extensions that compile a group of source
files together as a batch.
--
Barry Margolin, Thinking Machines Corp.

barmar at think.com
{uunet,harvard}!think!barmar



More information about the Comp.lang.c mailing list