Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!uupsi!cmcl2!lanl!cochiti.lanl.gov!jlg
From: jlg@cochiti.lanl.gov (Jim Giles)
Newsgroups: comp.lang.c
Subject: Re: low level optimization
Message-ID: <22355@lanl.gov>
Date: 23 Apr 91 15:06:26 GMT
References: <21660@lanl.gov> <1991Apr17.225944.15261@zoo.toronto.edu> <RJC.91Apr20023816@brodie.cstr.ed.ac.uk>
Sender: news@lanl.gov
Organization: Los Alamos National Laboratory
Lines: 21

In article <RJC.91Apr20023816@brodie.cstr.ed.ac.uk>, rjc@cstr.ed.ac.uk (Richard Caley) writes:
|> In article <21868@lanl.gov>, Jim Giles (jg) writes:
|>
|> jg> [...]          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.

Same as my third option.  The load-time tool actually does the 
interprocedural analysis.  Your solution merely makes the loader's
'code generation' duties simpler at the expense of more expensive
compilation and larger object files.  And, again, no implementation
does this (yet).

J. Giles