#4428: Local functions lose their unfoldings
---------------------------------+------------------------------------------
Reporter: rl | Owner:
Type: bug | Status: merge
Priority: normal | Milestone: 7.0.2
Component: Compiler | Version: 7.1
Keywords: | Testcase:
Blockedby: | Difficulty:
Os: Unknown/Multiple | Blocking:
Architecture: Unknown/Multiple | Failure: Runtime performance bug
---------------------------------+------------------------------------------
Comment(by rl):
Alas, it seems that local unfoldings need more work as the patch seems to
cause significant compile time increases and sometimes even to performance
regressions with vector code. The reason for this is quite simple. Suppose
we have this in module `Foo`:
{{{
{-# INLINE foo #-}
foo ... = let {-# INLINE [0] local #-}
local = <unoptimised rhs>
in
<foo rhs>
}}}
We now inline this into `bar` (in a different module), turning this:
{{{
bar = ... foo ...
}}}
into this:
{{{
bar = let {-# INLINE [0] local #-}
[Tmpl = <unoptimised rhs>]
local = <unoptimised rhs>]
in
... <foo rhs> ...
}}}
Now, GHC will merrily optimise both <foo rhs> and local's rhs but it will
not optimise local's unfolding before it is inlined. Thus, right before
phase 0 we will have:
{{{
bar = let {-# INLINE [0] local #-}
[Tmpl = <unoptimised rhs>]
local = <optimised rhs>]
in
... local ...
}}}
In phase 0, we will throw away local's optimised rhs, inline the
unoptimised unfolding and optimise that. In effect, we are optimising
local twice at every call site, leading to increased compile times.
Moreover, we only have one phase in which to optimise local's unfolding
after inlining it so might produce worse code than before.
I'm not sure what to do here. Local `INLINE` functions should probably be
treated specially somehow. Perhaps their unfoldings ought to be thrown
away and then rerecorded right before they can be inlined.
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/4428#comment:6>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
_______________________________________________
Glasgow-haskell-bugs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
