#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