[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 rwbarton):

 Replying to [comment:12 simonpj]:
 > > The same scenario could apply in reverse, right? In the actual xmlhtml
 package, `Text.XmlHtml.HTML.Meta` is the first module built and it is
 built with `-O0` so any interface files that are read while compiling that
 module will not have unfoldings attached. Then those modules will not have
 unfoldings during the compilation of any subsequent module either, even
 though those are built with `-O`.
 >
 > No, that part at least is not so.  The interface file built for
 `Text.XmlHtml.HTML.Meta` will not have unfoldings in it, but that only
 affects functions actually defined in `Text.XmlHtml.HTML.Meta`.  Later
 modules, built with `-O` will certainly get interface files with
 unfoldings in them.

 Sorry, I should have been more clear. I mean that when GHC builds
 `Text.XmlHtml.HTML.Meta`, causing it to read the interface file for
 `Data.String`, optimization level `-O0` is in effect, so GHC will not read
 the unfolding for `Data.String.fromString`. Then, when GHC builds the next
 module `Text.XmlHtml.Common`, even though it is now at optimization level
 `-O1`, it reuses its in-memory interface file information for
 `Data.String` and therefore has no unfolding available for `fromString`,
 so it cannot inline it.

 If we force GHC to build `Text.XmlHtml.Common` before
 `Text.XmlHtml.HTML.Meta` by adding an import of the former to the latter,
 then GHC does inline `fromString` in `Text.XmlHtml.Common`. You can
 observe this either with `-ddump-inlinings -dverbose-core2core`, or by
 examining the symbol table of the resulting object file: there is no
 reference to an undefined symbol `base_DataziString_fromString_info`.

 This doesn't just apply to the module `Data.String`, of course; we might
 be missing many other opportunities to inline when we build the rest of
 the modules in this package.

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