Re: optimizing (Torben Ęgidius Mogensen)
Mon, 15 Aug 2011 09:39:47 +0200

          From comp.compilers

Related articles
optimizing (glen herrmannsfeldt) (2011-08-12)
Re: optimizing (2011-08-13)
Re: optimizing (Hans Aberg) (2011-08-13)
Re: optimizing (Walter Banks) (2011-08-14)
Re: optimizing (2011-08-15)
Re: optimizing (Volker Birk) (2011-08-15)
Re: optimizing (Hans Aberg) (2011-08-15)
Re: optimizing (glen herrmannsfeldt) (2011-08-15)
| List of all articles for this month |

From: (Torben Ęgidius Mogensen)
Newsgroups: comp.compilers
Date: Mon, 15 Aug 2011 09:39:47 +0200
Organization: - Supporting Open source
References: 11-08-015
Keywords: optimize
Posted-Date: 15 Aug 2011 11:36:29 EDT

glen herrmannsfeldt <> 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.


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.