getting Core Haskell from GHC API with cross-module inlinings

Tim Chevalier catamorphism at
Mon Jun 21 14:45:50 EDT 2010

On 6/17/10, Roman Beslik <beroal at> wrote:
> Hi.
>  The following code compiles "A.hs" with GHC API:
>  {{{
>  import GHC
>  import Outputable
>  import DynFlags ( defaultDynFlags )
>  libdir = "/usr/lib/ghc-6.12.1"
>  targetFile = "A.hs"
>  main = defaultErrorHandler defaultDynFlags $ do
>     runGhc (Just libdir) $ do
>         dflags <- fmap (\dflags -> dflags {optLevel = 2}) getSessionDynFlags

Hi, Roman --

The problem you're seeing, where insufficient optimization occurs, is
in the above line. If I replace it with:

dflags <- fmap (updOptLevel 2) getSessionDynFlags

then I get a result where "maybe" has been inlined away. The reason is
that the optimization sequence is controlled by several different
fields within DynFlags, and just changing the optLevel field doesn't
update the other fields. The updOptLevel function (defined in
DynFlags, so you'll have to import that module explicitly) does.

Also, I don't know what you're trying to do, but I recommend looking
at GHC's External Core feature:
and at the extcore and linkcore libraries:

IMO, it's easier than using the API to generate Core. If you find any
problems with External Core or the packages above, let me know (I'm
the maintainer).


Tim Chevalier * * Often in error, never in doubt
"I knew I'd hate Cobol the moment I saw they'd used 'perform' instead
of 'do'." -- Larry Wall

More information about the Glasgow-haskell-users mailing list