low level optimization

[Henry Spencer]

In article <16692 at chaph.usc.edu> jeenglis at alcor.usc.edu (Joe English) writes:
>>  There is nothing non-conforming
>>about a compiler that does certain optimizations only in favorable situations,
>>e.g. when it is compiling all source modules involved...
>
>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.

Why do you assume that foo.o even exists?  The standard requires that it
exist at some point during the compilation of foo.c+bar.c, but it could
be only a compiler-internal temporary, with foobar.o being generated as
the result of the compilation.  Actually, there might not even be a .o
file, just the final a.out.  (Remember that the standard allows things
like C interpreters, so it is very carefully worded to place very few
constraints on how the results of translation show up.)

>Does the Standard say that it's OK for an implementation to 
>require recompilation of foo.c at this point?

I would tentatively interpret that as being legitimate only if foo.o was
not actually made available to the user.  Otherwise you would really have
to bend the rules to dodge around the "you can compile things separately
and link them later" part.  It's not actually breaking the rules, because
all they say is that there must be *a way* to do it, and maybe the way is
to compile files one at a time, but it's not going to endear the compiler
writer to his customers.

>>The
>>only constraint is that certain aspects of the external behavior of the
>>resulting program must not vary with such optimizations.
>
>If that's the case, and given that 'make' and similar utilities
>don't keep track of the compilation history, it would be extremely
>difficult to do any kind of cross-file interprocedural optimizations
>in a conforming C implementation for a conventional (e.g.,
>Unixlike) environment...

Why so?  When I say "external behavior", I mean of the generated code,
not of the compiler.  There are any number of ways you can contrive to
make things work, the simplest being the foobar.o approach that denies
any opportunity to make them not work.

You'd have to modify the Makefiles to feed such a compiler properly.
It's often necessary to modify Makefiles for the sake of odd compilers.
ANSI C does not place any constraints on that. :-)
-- 
And the bean-counter replied,           | Henry Spencer @ U of Toronto Zoology
"beans are more important".             |  henry at zoo.toronto.edu  utzoo!henry