GHC: Ticket #7112: No inlining in the presence of non-instantiated phantom type
http://ghc.haskell.org/trac/ghc/ticket/7112
<p>
Consider the following code:
</p>
<pre class="wiki">data U a = U
g :: [U a]
g = [U]
f :: [Int]
f = map (\U -> 2) g
</pre><p>
Compiled with -O1, <tt>g</tt> does not get inlined, and <tt>f</tt> stays unchanged. Inline pragmas don't seem to help. However, if we change the type signature of <tt>g</tt> to instantiate the phantom type parameter, such as with <tt>g :: [U ()]</tt>, then <tt>f</tt> is nicely optimised to become <tt>[2]</tt>. I believe this is a bug, and we'd like <tt>f</tt> to be simplified even when <tt>g</tt> has its most general type signature.
</p>
en-usGHChttp://ghc.haskell.org/trac/ghc/chrome/site/ghc_logo.png
http://ghc.haskell.org/trac/ghc/ticket/7112
Trac 1.0.7simonpjWed, 15 Aug 2012 14:52:57 GMTpriority changed; difficulty set
http://ghc.haskell.org/trac/ghc/ticket/7112#comment:1
http://ghc.haskell.org/trac/ghc/ticket/7112#comment:1
<ul>
<li><strong>priority</strong>
changed from <em>normal</em> to <em>low</em>
</li>
<li><strong>difficulty</strong>
set to <em>Unknown</em>
</li>
</ul>
<p>
This is a bit perplexing, I agree. Here is what is happening. In the monomorphic case we get
</p>
<pre class="wiki">g :: [U ()]
g = Cons (U ())
(U ())
(Nil (U ())
f = map ... g
</pre><p>
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:
</p>
<pre class="wiki">g :: forall a. [U a]
g = /\a. Cons (U a)
(U a)
(Nil (U a)
f = map ... (g ())
</pre><p>
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.
</p>
<p>
Moreover, the RULES for map (actually they are for foldr) are very specific (see GHC.Base):
</p>
<pre class="wiki">"foldr/single" forall k z x. foldr k z [x] = k x z
"foldr/nil" forall k z. foldr k z [] = z
</pre><p>
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.)
</p>
<p>
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?
</p>
TicketnfrisbyTue, 21 Aug 2012 16:08:51 GMTcc set
http://ghc.haskell.org/trac/ghc/ticket/7112#comment:2
http://ghc.haskell.org/trac/ghc/ticket/7112#comment:2
<ul>
<li><strong>cc</strong>
<em>nfrisby</em> added
</li>
</ul>
TicketiglooFri, 12 Oct 2012 10:36:54 GMTstatus changed; resolution set
http://ghc.haskell.org/trac/ghc/ticket/7112#comment:3
http://ghc.haskell.org/trac/ghc/ticket/7112#comment:3
<ul>
<li><strong>status</strong>
changed from <em>new</em> to <em>closed</em>
</li>
<li><strong>resolution</strong>
set to <em>wontfix</em>
</li>
</ul>
<p>
If this isn't important enough to spend time on, then let's just close the ticket.
</p>
Ticket