Simplify.hs depends on typechecker

Joachim Breitner mail at
Tue Oct 24 15:40:29 UTC 2017


while rebuilding Simplify.o only I noticed that all of the type
checker, and HsSyn stuff, and renamer stuff, and so needed to be
rebuilt, which I found strange.

After a little investigation, it seems that the simplifier depends on
CoreMonad, and that pulls some very few type-checker related things:

    import TcRnMonad        ( initTcForLookup )
    import {-# SOURCE #-} TcSplice ( lookupThName_maybe )


    thNameToGhcName :: TH.Name -> CoreM (Maybe Name)
    thNameToGhcName th_name = do
        hsc_env <- getHscEnv
        liftIO $ initTcForLookup hsc_env (lookupThName_maybe th_name)

which is not even used in GHC, but only in GHC Plugins, so this could
probably be moved to a separate module pulled in by GhcPlugins.hs


    import TcEnv            ( lookupGlobal )


    instance MonadThings CoreM where
        lookupThing name = do { hsc_env <- getHscEnv
                              ; liftIO $ lookupGlobal hsc_env name }

This might be a bit harder to disentangle. But if successful, it would
probably make building GHC in parallel quite a bit faster. And it just
seems strange to me that the Core-to-Core code should depend on the
type checker…

I’m sending this out there in case someone has dug in that direction
before and has insights to share.


(Attached is a transitively reduced dependency graph of Simplify.hs,
created using Iavor’s

Joachim “nomeata” Breitner
  mail at
-------------- next part --------------
A non-text attachment was scrubbed...
Name: foo.pdf
Type: application/pdf
Size: 50924 bytes
Desc: not available
URL: <>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <>

More information about the ghc-devs mailing list