[GHC] #15056: Wrappers inlined too late
GHC
ghc-devs at haskell.org
Thu Apr 19 14:54:47 UTC 2018
#15056: Wrappers inlined too late
-------------------------------------+-------------------------------------
Reporter: simonpj | Owner: (none)
Type: bug | Status: new
Priority: normal | Milestone: 8.6.1
Component: Compiler | Version: 8.2.2
Keywords: | Operating System: Unknown/Multiple
Architecture: | Type of failure: None/Unknown
Unknown/Multiple |
Test Case: | Blocked By:
Blocking: | Related Tickets:
Differential Rev(s): | Wiki Page:
-------------------------------------+-------------------------------------
Consider these two modules
{{{
module Foo where
test :: Int -> Bool
test 0 = True
test n = test (n-1)
foo :: Foldable t => Int -> t Int -> Int
foo n xs | test n
= foldr (+) n xs
| otherwise
= n+7
}}}
and
{{{
module Bar where
import Foo
blam x = f 3 [1..x]
}}}
If we simply inline `foo` into `blam`, we get `foldr/build` fusion. And
that is exactly what happens if you compile `Foo` with `-fno-strictness`.
But what actually happens is
* When compiling `Foo`, strictness analysis does worker/wrapper for
`foo`.
* The wrapper currently gets an aciviation of "active only in phase 0";
see `Note [Wrapper activation]` in `WorkWrap`.
* So `foo` is ultimately inlined (actually its worker is inlined too) but
too late for fusion to take place.
This is bad: optimising `Foo` makes the overall runtime increase.
I have seen other examples of this. The general pattern is:
* Without worker/wrapper, a function `f` may inline, which exposes
opportunities for functions in its body to participate in rule rewrites
* With worker/wrapper, no inlining happens until phase 0; and that is too
late for the rules to fire.
Obvious thought: allow wrappers from strictness analysis to inline
earlier. I'll try that.
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15056>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
More information about the ghc-tickets
mailing list