|optimizing firstname.lastname@example.org (glen herrmannsfeldt) (2011-08-12)|
|Re: optimizing email@example.com (2011-08-13)|
|Re: optimizing firstname.lastname@example.org (Hans Aberg) (2011-08-13)|
|Re: optimizing email@example.com (Walter Banks) (2011-08-14)|
|Re: optimizing firstname.lastname@example.org (2011-08-15)|
|Re: optimizing email@example.com (Volker Birk) (2011-08-15)|
|Re: optimizing firstname.lastname@example.org (Hans Aberg) (2011-08-15)|
|Re: optimizing email@example.com (glen herrmannsfeldt) (2011-08-15)|
|From:||firstname.lastname@example.org (Torben Ęgidius Mogensen)|
|Date:||Mon, 15 Aug 2011 09:39:47 +0200|
|Organization:||SunSITE.dk - Supporting Open source|
|Posted-Date:||15 Aug 2011 11:36:29 EDT|
glen herrmannsfeldt <email@example.com> writes:
> A recent post to comp.lang.fortran on optimization reminded me of
> something I thought about some time ago. Someone was wondering if any
> optimization was done at link time. In the case of Fortran, the
> answer is usually no.
> It seems to me, though, that in the case of RISC, and even more in the
> case of VLIW processors like Itanium, delaying the final optimization
> and code generation pass would be useful.
A variant of this is whole-program compilation: Each module is,
individually, just type-checked and, perhaps, simplified somewhat
(expanding macros and syntactic sugar), but the real code generation
does not happen until you combine the modules into a single
executable. This allows, for example, inlining across modules and
program-wide dataflow analysys (which can give much better results
for, e.g, alias analysis).
The downside is, of course, much longer compilation times. But if you
have a sufficiently strong type system, many bugs will be caught
already when you compile individual modules, so you don't compile the
whole program as often. This is why this approach is more common for
strongly-typed functional languages than for C-like languages.
Return to the
Search the comp.compilers archives again.