getting Core Haskell from GHC API with cross-module inlinings

[Tim Chevalier]

On 6/17/10, Roman Beslik <beroal at ukr.net> 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:
http://www.haskell.org/ghc/docs/6.12.2/html/users_guide/ext-core.html
and at the extcore and linkcore libraries:
http://hackage.haskell.org/package/extcore
http://hackage.haskell.org/package/linkcore

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).

Cheers,
Tim

-- 
Tim Chevalier * http://cs.pdx.edu/~tjc * 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