[GHC] #9243: Recompilation avoidance works imperfectly with -fno-code/-fwrite-interface

27 Jun 2014

      #9243: Recompilation avoidance works imperfectly with -fno-code/-fwrite-interface
-------------------------+-------------------------------------------------
       Reporter:         |             Owner:
  ezyang                 |            Status:  new
           Type:  bug    |         Milestone:
       Priority:         |           Version:  7.9
  normal                 |  Operating System:  Unknown/Multiple
      Component:         |   Type of failure:  Compile-time performance bug
  Compiler               |         Test Case:
       Keywords:         |          Blocking:
   Architecture:         |
  Unknown/Multiple       |
     Difficulty:         |
  Unknown                |
     Blocked By:         |
Related Tickets:         |
-------------------------+-------------------------------------------------
 With the latest `-fwrite-interface` enhancements, a build directory can
 contain interface files independently of object files. In cases like this,
 we would like to have recompilation avoidance avoid typechecking files
 whose interface files are up-to-date.

 However, this does not currently work: we always re-typecheck:

 {{{
 t-edyang@cam-05-unx:/5playpen/t-edyang/sandbox/q$ /5playpen/t-edyang/ghc-
 backpack/inplace/bin/ghc-stage2 --make A.hs -fno-code -fwrite-interface
 [1 of 1] Compiling A                ( A.hs, nothing )
 t-edyang@cam-05-unx:/5playpen/t-edyang/sandbox/q$ /5playpen/t-edyang/ghc-
 backpack/inplace/bin/ghc-stage2 --make A.hs -fno-code -fwrite-interface
 [1 of 1] Compiling A                ( A.hs, nothing )
 }}}

 The reason for this is that recompilation avoidance logic in `compileOne`
 (in `DriverPipeline.hs`) seems to rely exclusively on "linkables" in order
 to figure out if source has been modified or not. We never generate an
 object file with `-fwrite-interface`, so the compiler always concludes
 that we need to retypecheck.

 However, recompilation avoidance for hs-boot does work. The reason for
 this is because we create a dummy o-boot linkable. We can't use this
 strategy for `-fno-code`, because the dummy object file would imply that
 we actually compiled the file (which we didn't).

 The upshot is that to fix this problem, it looks like we might have to
 rejigger all of the logic in `compileOne`, which why I gave up on this for
 now.

 Related to https://github.com/haskell/cabal/issues/1179

--
Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9243
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler