whole program optimization
Isaac Dupree
isaacdupree at charter.net
Sun Dec 23 07:35:20 EST 2007
GHC optimizes less effectively when parts of a program are in different
modules, or are exported from a module. Therefore, merging all the code
into one "module Main (main)" would help. Unfortunately, Haskell source
syntax is ill-suited to this; for example:
module-boundary monomorphism restriction
different defaults in different modules
deriving (Show, Read) --for renaming everything that's
-- in different modules, so it doesn't conflict
new GHC "{..}" etc. record stuff
imports as, unknown import lists....
Also, program correctness can be wrongly increased; for example, using
instances that were defined in some module imported by Main, but not by
the module that uses the instance. I suppose this might affect
overlapping instances somehow?
But it seems plausible to merge modules on the GHC Core level, after
desugaring and type-checking. Then the one infelicity would be that
orphan RULES could apply in more places (RULES are converted and applied
to Core!). Is this a problem? Does it already happen when modules
import small inlinings from .hi files of modules that don't have access
to the RULES?
It would not actually be quite "whole-program" as long as all the
libraries are compiled separately and only available through their .o
and incomplete .hi files. Which is okay; but it would be nice if they
could all also be compiled to the "complete-.hi" that we thought might
serve for External Core -- and then one would just need to tell GHC to
take all those complete-.hi's and compile them together into one
executable. (except for complications like C _stub files, etc, etc.
Also some parts of `base` might be wired-in enough that they need some
thought before messing with them.) Then _any_ function that was only
used once would be inlined, and GHC would generally be free to make
decisions like that (at the GHC-speed price of having to look at all
program and library code in detail) (however the GHC interface to this
works, Cabal could probably help automate it somehow?)
(Unfortunately, ghc-haskell source syntax doesn't provide an easy way to
encode Core, even if we wanted to convert it back into GHC-compilable
Haskell, without unsafeCoerce everywhere, I think?)
So it's more complicated than it seems on the surface, but it could be
done; I only wonder how effective it would be on various programs. I
assume GHC doesn't currently implement any optimizations that can _only_
be whole-program, so it would still not be quite like Jhc, though this
basic support might allow some such optimizations to be implemented.
Isaac
More information about the Glasgow-haskell-users
mailing list