Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!emory!gatech!purdue!haven!ni.umd.edu!uc780.umd.edu!cs450a03
From: cs450a03@uc780.umd.edu
Newsgroups: comp.lang.c
Subject: RE: low level optimization
Message-ID: <18APR91.23320108@uc780.umd.edu>
Date: 18 Apr 91 23:32:01 GMT
References: <1991Apr18.185442.7546@zoo.toronto.edu> <21848@lanl.gov> <1991Apr18.233653.19435@zoo.toronto.edu> <16692@chaph.usc.edu>
Sender: usenet@ni.umd.edu (USENET News System)
Organization: The University of Maryland University College
Lines: 26

Joe English writes:
   [about inter-procedural optimization]
>What happens, then, if you compile foo.c and bar.c together, and
>later change and recompile bar.c alone?  foo.o (or its equivalent)
>might have been optimized to use information that's no longer valid.
>Does the Standard say that it's OK for an implementation to require
>recompilation of foo.c at this point?

It might be worth pointing out that if a compiler was designed with
the option of doing inter-procedural analysis, and if that option were
used, there would be no need to have generated a "foo.o" in the first
place.

Note that I'm not saying that there would be no intermediate files,
just that they should not be confusable with intermediate files used
for independent compilation.

Also note that I'm not saying that the compiler couldn't generate
"foo.o" -- maybe somebody would throw in a switch to gratuiously
create independent object files even though compiling with
inter-procedural optimization turned on.

Finally, note that I know of no such compiler, and I'm not about to
write one.

Raul Rockwell