low level optimization

[Jim Giles]

> I don't believe the C Standard requires that a compiler capable of the
> above generate the separate "object" files A.o and B.o when they are
> somehow "compiled together".  My understanding is that it could instead
> generate the "object" file AB.o.  Thus, your problem can't occur: you
> can't link A.o against a re-compiled B.o *unless* you generated A.o
> separately as well.

Well, my example was the other way around (I postulated retranslating
A and not B), but I'll use you version just as well.  The standard says
that I _may_ link a fresh translaton of B with previously translated
files (like A for example).  It does _not_ say that I can only do this
if A was not previously translated with an older version of B or anything
to that effect.  (Note again: anything the standard says I _may_ do,
the implementation _must_ permit me to do.)  

To reiterate, the standard says I may link translated files to previously
translated ones to form programs.  It places no constraints on this.  As
long as each translated file is itself standard conforming, linking them
together is a capability required by the standard.

Now, it _does_ make linkage of translated units based on the definition
of the units as "source files".  So, I would read that to mean that
interprocedural analysis and optimization _is_ allowed between functions
defined in the _same_ source file.  This is contrary to the standard
practice of putting functions definitions into separate files as much
as is possible.  Further, I've not seen any compilers which take advantage
of this method of optimization.  In fact, Pascal did not even allow 
separate compilation and I never saw a Pascal compiler which did inter-
procedural analysis either - compiler technology just hasn't quite got
to to the point where such analysis is the commonplace of production
compilers.  When it does become commonplace, care must be exercised
in applying it to C and still claiming standard conformance.

J. Giles