[GHC] #9370: unfolding info as seen when building a module depends on flags in a previously-compiled module

[GHC]

#9370: unfolding info as seen when building a module depends on flags in a
previously-compiled module
-------------------------------------+-------------------------------------
              Reporter:  carter      |            Owner:
                  Type:  bug         |           Status:  new
              Priority:  high        |        Milestone:  7.10.1
             Component:  Compiler    |          Version:  7.8.3
            Resolution:              |         Keywords:
      Operating System:              |     Architecture:  Unknown/Multiple
  Unknown/Multiple                   |       Difficulty:  Unknown
       Type of failure:  Compile-    |       Blocked By:
  time performance bug               |  Related Tickets:
             Test Case:              |
              Blocking:              |
Differential Revisions:              |
-------------------------------------+-------------------------------------

Comment (by simonpj):

 Hmm.  Is this with `ghc --make`?  Then yes, that sounds plausible.

   * When compiling a module M with -O, and then reading an interface file
 to support that compilation, GHC makes the unfolding of Ids in that
 interface file.

   * With `ghc --make` when GHC goes on to compile a new module L, it
 doesn't re-read interface files it has already read (that is part of why
 `--make` is faster). So the already-read Ids still have those unfoldings
 in them.

   * As a result, if L is compiled with -O0, it will still see the
 unfoldings.

 I can see that is perplexing.  If it's important, the solution would be to
 disable inlining for imported functions when -O0 is on. (Actually, more
 precisely, it's controlled by `-fignore-interface-pragmas`.)  I don't
 think it would be terribly hard to do that, although it would be an extra
 test on every inlining for an imported function.

 I still wish someone could explain why it's so crucial for this module to
 be compiled with -O0. That must be a bug, either in the RULES for some
 package, or in GHC.

 Simon

--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9370#comment:10>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler