[GHC] #14103: Retypechecking the loop in --make mode is super-linear when there are many .hs-boot modules
#14103: Retypechecking the loop in --make mode is super-linear when there are many .hs-boot modules -------------------------------------+------------------------------------- Reporter: duog | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 Keywords: hs-boot | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- At time of writing master is at commit 14457cf6a50f708eecece8f286f08687791d51f7. In GhcMake.hs, both upsweep and parUpsweep call getModLoop for each module. getModLoop is (at least) linear when called on a .hs-boot ModSummary. See comments in Phab:3646. This isn't a big deal in practice, since .hs-boot modules are uncommon, but it does irk me, and it will be easy to fix. Fixing this would also be an opportunity to de-duplicate some logic in upsweep and parUpsweep. ccing niteria as he has worked with this code recently. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14103 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#14103: Retypechecking the loop in --make mode is super-linear when there are many .hs-boot modules -------------------------------------+------------------------------------- Reporter: duog | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 Resolution: | Keywords: hs-boot Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by niteria): If there's a cleaner way to do it, I'm all for it. I was conservative with my fix, because there was some code I didn't understand and I didn't want to change the behavior. For example: https://phabricator.haskell.org/diffusion/GHC/browse/master/compiler/main/Gh... If there are loops with multiple (say A.hs-boot, B.hs-boot, C.hs-boot) hs- boot modules, it would extract a cycle with A.hs-boot, B.hs-boot, C.hs- boot, a cycle with B.hs-boot, C.hs-boot, and a cycle with C.hs-boot. Why? I don't know. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14103#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#14103: Retypechecking the loop in --make mode is super-linear when there are many .hs-boot modules -------------------------------------+------------------------------------- Reporter: duog | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 Resolution: | Keywords: hs-boot Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ezyang): I would say, go for it. I suspect the weird behavior niteria describes was unintentional (or intentional, but only in the sense that it is easier to implement) and you can probably simplify it a lot. But do note that if the set of modules that gets retypechecked *changes*, that could introduce a bug. But there is some code in between getModLoop and the actual retypechecking... -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14103#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#14103: Retypechecking the loop in --make mode is super-linear when there are many .hs-boot modules -------------------------------------+------------------------------------- Reporter: duog | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 Resolution: | Keywords: hs-boot Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by duog): I think the current behaviour is correct. This is a complicated topic, so the explanation below is complicated, with lots of parenthesis! For the purposes of retypechecking, the loops are only used for their module names. There is one loop per hs-boot file. When we go to compile a hs file that has an hs-boot file (and therefore finishes a loop), the home package table has a ModDetails for this module (built from the hs-boot file), and all modules that transitively import that hs-boot file have been typechecked against that ModDetails. We retypecheck (i.e. rebuild their ModDetails from their interface) all those modules (but NOT the hs- boot modules) before typechecking the loop closer, then replace it's hs- boot ModDetails in the home package tables with it's full ModDetails. We then retypecheck the loop again, so that Ids in modules that imported the hs-boot module have their unfoldings attached. (although maybe this is wrong, see trac:14092) Note that it doesn't matter whether the modules we retypechecked were hs- boot interfaces or full hs interfaces. I think this is the key point. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14103#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
participants (1)
-
GHC