[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