Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!wuarchive!hsdndev!cmcl2!lanl!cochiti.lanl.gov!jlg
From: jlg@cochiti.lanl.gov (Jim Giles)
Newsgroups: comp.lang.c
Subject: Re: low level optimization
Message-ID: <22246@lanl.gov>
Date: 22 Apr 91 15:10:52 GMT
References: <21961@lanl.gov> <11129@ncar.ucar.edu>
Sender: news@lanl.gov
Organization: Los Alamos National Laboratory
Lines: 29


> Scenario #1 (demonstration of global-optimization):
> 
>	$ cc -O3 -o foobar.o -c foo.c bar.c
>	$ cc foobar.o
>
> Scenario #2 (demonstration of the *required* functionality of incremental
> compilation):
>
>	$ cc -O -c foo.c
>	$ cc -O -c bar.c
>	$ cc foo.o bar.o

The point you seem to miss is that after scenario 1, the vendor will 
ship foobar.o to the customer.  Later, the vendor may change _just_
bar.c.  He will recompile it and send bar.o to the customer.  The
customer will then link bar.o and foobar.o to yield a program with the
new version of bar in it.  The standard says the vendor _may_ do this.
Which means that the implementation _must_ allow it to be done.

Since the end user never has foo.c (and doesn't even know whether
foo was really written in C or not), scenario 2 is not relevant to
the discussion.

J. Giles

P.S.  As I keep pointing out, the _loader_ (or some load-time tool)
_can_ satisfy the standard and still do intermodule optimization.
The 'translator' (usually thought of as the compiler) cannot.