[GHC] #6040: Adding a type signature changes heap allocation into stack allocation without changing the actual type

[GHC]

#6040: Adding a type signature changes heap allocation into stack allocation
without changing the actual type
---------------------------------+------------------------------------------
    Reporter:  tibbe             |       Owner:                  
        Type:  bug               |      Status:  new             
    Priority:  normal            |   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):

  * difficulty:  => Unknown


Comment:

 Can you give a repo case that shows a performance effect?

 I'm guessing, but I think that the difference is something like this:
 {{{
 f1 x = g 100                   f2 x = g x 0
   where                          where
     g 0 = x                        g x 0 = x
     g n = g (n-1)                  g x n = g x (n-1)
 }}}
  * In `f1` we'll heap-allocate a function closure capturing the free
 variable `x`, but the recursive calls have just one argument (plus one for
 the function closure itself).
  * In `f2` we'll pass `x` as an argument.  Indeed `g` will be floated out
 to be a top-level function.  (And in the example you give I don't
 undersatnd why `go` and `insert` are separate functions, but that's a
 stylistic thing.)

 If there were 100 free varaibles instead of 1, it might well be a good
 plan to use `f1`, to save passing 100 arguments in each call.  But since
 there is only one it'd be better to turn the free variable into an
 argument, by lambda lifting.  This is the reverse of the "static argument
 transformation".

 The transformation should be done right at the end, because in general
 turning a free varaible into an argument is a bad idea (loss of
 information).

 I've been meaning to do this for some time; if you have data to show it's
 important I could up the priority!

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/6040#comment:1>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler