low level optimization

[Richard Caley]

In article <21868 at lanl.gov>, Jim Giles (jg) writes:

jg> Suppose
jg> that functions A and B are in two separate files.  Suppose that
jg> I compile them 'together' in some way (that is, the compiler makes
jg> some use of internal knowledge of B while translating A and vice-versa).
jg> Now, suppose I _change_ A and retranslate just A (I do _not_ retranslate
jg> B).  The standard requires that I still be able to link both into a
jg> single program.  If the translation of B made any _profitable_ use
jg> of internal information about A, then that information is obsolete
jg> (and probably downright _wrong_) after A has been changed.  Yet, the
jg> standard requires that the new version of A still be usable with the
jg> previously translated B.  Either the use the translator made of the
jg> interprocedural analysis was trivial, or B will contain unsafe
jg> optimizations - the only third way is if 'translation' does not
jg> include code generation (which will subsequently be done by some
jg> post-translation tool: like the loader - just like I keep saying).

Fourth option:

When compiling `together' the compiler creates object files
containing two complete sets of code, data etc. The linker looks at
the object files given and if they were not all compiled together (eg
if you had recompiled one) it uses the non-optimised code.

I'm sure the net.experts can come up with much better solutions, this
is simply the one which was most obvious to me.

--
rjc at cstr.ed.ac.uk		_O_
				 |<