[GHC] #9370: unfolding info as seen when building a module depends on flags in a previously-compiled module
GHC
ghc-devs at haskell.org
Mon Oct 24 10:44:17 UTC 2016
#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
More information about the ghc-tickets
mailing list