The same scenario could apply in reverse, right? In the actual xmlhtml
#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]: 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