[GHC] #7112: No inlining in the presence of non-instantiated phantom type
GHC
cvs-ghc at haskell.org
Wed Aug 15 16:52:58 CEST 2012
#7112: No inlining in the presence of non-instantiated phantom type
---------------------------------+------------------------------------------
Reporter: dreixel | Owner:
Type: bug | Status: new
Priority: low | Milestone:
Component: Compiler | Version: 7.4.1
Keywords: | Os: Unknown/Multiple
Architecture: Unknown/Multiple | Failure: None/Unknown
Difficulty: Unknown | Testcase:
Blockedby: | Blocking:
Related: |
---------------------------------+------------------------------------------
Changes (by simonpj):
* priority: normal => low
* difficulty: => Unknown
Comment:
This is a bit perplexing, I agree. Here is what is happening. In the
monomorphic case we get
{{{
g :: [U ()]
g = Cons (U ())
(U ())
(Nil (U ())
f = map ... g
}}}
So the rule for 'map' that cancels with a 'Cons' can "see" the Cons in g's
RHS. But in the polymorphic case we have:
{{{
g :: forall a. [U a]
g = /\a. Cons (U a)
(U a)
(Nil (U a)
f = map ... (g ())
}}}
And now the fact that 'g' is a 'Cons' is not so obvious any more.
Inlining g is not a great plan because doing so means the Cons will be
dynamically allocated rather than statically allocated.
Moreover, the RULES for map (actually they are for foldr) are very
specific (see GHC.Base):
{{{
"foldr/single" forall k z x. foldr k z [x] = k x z
"foldr/nil" forall k z. foldr k z [] = z
}}}
even a list of length 2 would't optimise. (There's a reason for this; if
the list is of length 1000 we don't want unroll the map.)
So although it's odd I don't think it's important enough to burn cycles
on. Or do you havea compelling reason in some larger context?
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7112#comment:1>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
More information about the Glasgow-haskell-bugs
mailing list