Simplify.hs depends on typechecker
Hi, 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: 1. import TcRnMonad ( initTcForLookup ) import {-# SOURCE #-} TcSplice ( lookupThName_maybe ) for 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 2. import TcEnv ( lookupGlobal ) for 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. Greetings, Joachim (Attached is a transitively reduced dependency graph of Simplify.hs, created using Iavor’s https://github.com/yav/graphmod/wiki). -- Joachim “nomeata” Breitner mail@joachim-breitner.de https://www.joachim-breitner.de/
I agree. Both of these code paths go through initTcForLookup which is massive overkill, as the comment with `TcEnv.lookupGlobal` says. There's clearly a ToDo here to strip off the redundant stuff and do a minimal lookup. Would you like to make a ticket? Simon | -----Original Message----- | From: ghc-devs [mailto:ghc-devs-bounces@haskell.org] On Behalf Of | Joachim Breitner | Sent: 24 October 2017 16:40 | To: ghc-devs@haskell.org | Subject: Simplify.hs depends on typechecker | | Hi, | | 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: | | 1. | import TcRnMonad ( initTcForLookup ) | import {-# SOURCE #-} TcSplice ( lookupThName_maybe ) | | for | | 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 | | 2. | | import TcEnv ( lookupGlobal ) | | for | | 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. | | | Greetings, | Joachim | | (Attached is a transitively reduced dependency graph of Simplify.hs, | created using Iavor’s | https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub | .com%2Fyav%2Fgraphmod%2Fwiki&data=02%7C01%7Csimonpj%40microsoft.com%7Cb | 16c817556de4d55d74c08d51af5a8cd%7C72f988bf86f141af91ab2d7cd011db47%7C1% | 7C0%7C636444565247573129&sdata=oHpA%2F%2BHGyc0mHv%2FWj3nzGBiJCM2ufriryF | oZYNHSjqk%3D&reserved=0). | | | -- | Joachim “nomeata” Breitner | mail@joachim-breitner.de | | https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.jo | achim- | breitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cb16c817556de4d5 | 5d74c08d51af5a8cd%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63644456 | 5247583137&sdata=wO14DxiOaXUOx59N22YoS%2FoC2%2Bi4IEp3bNnB4Dli12U%3D&res | erved=0
participants (2)
-
Joachim Breitner -
Simon Peyton Jones