#4428: Local functions lose their unfoldings
---------------------------------+------------------------------------------
Reporter: rl | Owner:
Type: bug | Status: new
Priority: normal | Milestone:
Component: Compiler | Version: 7.1
Keywords: | Testcase:
Blockedby: | Difficulty:
Os: Unknown/Multiple | Blocking:
Architecture: Unknown/Multiple | Failure: Runtime performance bug
---------------------------------+------------------------------------------
Comment(by simonpj):
A fix for the late inlining of foo:
{{{
Mon Oct 25 08:26:22 PDT 2010 simo...@microsoft.com
* Do not (ever) use substExprSC in the simplifier
"Short-cut" substitution means "do nothing if the substitution
is empty". We *never* want do to that in the simplifier because
even though the substitution is empty, the in-scope set has
useful information:
* We get up-to-date unfoldings; and that in turn may
reduce the number of iterations of the simplifier
* We avoid space leaks, because failing to substitute may
hang on to old Ids from a previous iteration
(This is what was causing the late inlining of foo in
Trac #4428.)
M ./compiler/coreSyn/CoreSubst.lhs -6 +8
M ./compiler/simplCore/SimplEnv.lhs -8 +16
}}}
It's only a performance fix, but I believe it could close a space leak, so
probably worth merging when convenient.
The main bug is fixed by this:
{{{
Mon Oct 25 08:28:17 PDT 2010 simo...@microsoft.com
* Serialise nested unfoldings across module boundaries
As Roman reported in #4428, nested let-bindings weren't
being recorded with their unfoldings. Needless to say,
fixing this had more knock-on effects than I expected.
M ./compiler/coreSyn/CorePrep.lhs -3 +7
M ./compiler/coreSyn/CoreTidy.lhs -12 +38
M ./compiler/iface/BinIface.hs -5 +12
M ./compiler/iface/IfaceSyn.lhs -21 +23
M ./compiler/iface/IfaceType.lhs -11 +18
M ./compiler/iface/MkIface.lhs -23 +15
M ./compiler/iface/TcIface.lhs -35 +40
M ./compiler/main/TidyPgm.lhs -25 +5
}}}
and
{{{
Tue Oct 26 01:17:57 PDT 2010 simo...@microsoft.com
* Fix initialisation of strictness in the demand analyser
Previously, the demand analyser assumed that every binder
starts off with no strictness info. But now that we are
preserving strictness on nesting bindings in interface files,
that assumption is no longer correct, because an inlined function
might have a nested binding with strictness set.
So we need to know when we are in the initial sweep, so that we can
set the strictness to 'bottom'.
See Note [Initialising strictness]
M ./compiler/stranal/DmdAnal.lhs -112 +151
}}}
These are bigger changes, and there's a small change to the format of
interface files too, so I'm not certain about merging. Roman: is this a
big deal for 'vector'?
Simon
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/4428#comment:1>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
_______________________________________________
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
