[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:  richardfung
            Type:  bug               |               Status:  new
        Priority:  high              |            Milestone:  8.2.1
       Component:  Compiler          |              Version:  7.8.3
      Resolution:                    |             Keywords:  newcomer,
                                     |  Inlining
Operating System:  Unknown/Multiple  |         Architecture:
 Type of failure:  Compile-time      |  Unknown/Multiple
  performance bug                    |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:  #8635             |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by mpickering):

 t is certainly hard work on the first ticket. I spent about an hour
 this morning trying to find out where the right part to change was and
 then read Ben's email earlier in this thread which made everything
 much clearer for me!

 The essential problem we are trying to solve is:

 > When a module is compiled with -O0, it does not read unfoldings from
 modules it imports. Because we reuse the unfolding information across
 modules (to avoid reloading interface files very often), this unfolding
 information is then not available in the rest of the compilation pipeline.

 Simon's suggested fix is

 1. Always read in unfoldings, etc, including with -O. (Possible
 exception: one-shot mode.)
 2. Check the -fignore-interface-pragmas flag when considering inlining
 a function.

 So for part 1, we need to find the part which deals with *reading in*
 interface files and seeing where the unfolding information is lost.

 For part 2, we need to find the part of the optimiser which makes
 decisions about whether to inline a function.

 So now I'm re-reading Ben's comment and (as usual) his analysis is
 spot-on. If you trace the origin of the ignore_prags flag then you'll
 find it is set by checking whether the option
 `Opt_IgnoreInterfacePragmas` is set or not. You can find that this
 flag is automatically set when the opt-level is 0 in DynFlags, I'll
 leave you to find the exact location!

 It seems like Simon's suggested fix is removing this guard in
 loadDecls. It isn't clear to me whether the other information (other
 than the unfoldings) should still be read in or not. Simon will be
 able to comment.

 Now for part 2: I think you should start by looking at the
 callSiteInline function in coreSyn/CoreUnfold. That will at least get
 you started looking in the right place.

 Does that help?

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