#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: 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 simonpj): Actually we really don't want to disable ALL unfoldings, just unfoldings for imported things. Locally-bound things (esp in local lets) should be fine. I suppose that means that every use of `idUnfolding` has to be guarded with a test of `DynFlags`. The "is it imported?" test can be `isLocalVar`. I took a look at uses of `idUnfolding`. * Some, like `idUnfoldingFVs` can be dealt with by testing for `isLocalVar`. Global vars will have no fvs, so no point in looking at the unfolding. This might even improve perf! * Some, like the use of `idUnfolding` in `CoreLint` are guaranteed to be on a `LocalId`, so that can be an assertion. * The`isCompulsoryUnfolding` in `CoreSubst` is OK; we do want to inline conpulsory unfoldings regardless. Etc. It's tiresome to look at all these call sites, but I see no alternative. We have an Id that does ''have'' an unfolding, but we don't want to look at it.... -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9370#comment:44 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler