[GHC] #2607: Inlining defeats selector thunk optimisation

[GHC]

#2607: Inlining defeats selector thunk optimisation
---------------------------------+------------------------------------------
    Reporter:  simonmar          |        Owner:              
        Type:  bug               |       Status:  new         
    Priority:  normal            |    Milestone:  _|_         
   Component:  Compiler          |      Version:  6.8.3       
    Keywords:                    |     Testcase:              
   Blockedby:                    |   Difficulty:  Unknown     
          Os:  Unknown/Multiple  |     Blocking:              
Architecture:  Unknown/Multiple  |      Failure:  None/Unknown
---------------------------------+------------------------------------------

Comment(by batterseapower):

 Does GHC deal with selector thunks on sum types as well? Presumably you
 even can transform:

 {{{
 z = ... (case p72 of (x:_) -> e1; [] -> e2)
 }}}

 Into:
 {{{
 z = ... (case p72 of (_:_) -> e1; [] -> e2)
 x = case p72 of (x:_) -> x
 }}}

 This even extends to the case where both case branches bind variables,
 since the new selector thunks will only be evaluated in branches that
 guarantee the selector pattern match will succeed.

 The sad part is that the FVs of p72 will be kept alive by the non-selector
 expression:

 {{{
 case p72 of (_:_) -> e1; [] -> e2
 }}}

 Even though we don't want either field. We could transform like this
 instead:

 {{{
 z = ... (case tag of 1 -> e1; 2 -> e2)
 tag = case p72 of (_:_) -> 1; [] -> 2
 x = case p72 of (x:_) -> x
 }}}

 And then have the garbage collector speculatively evaluate "tag-selector
 thunks" too. This would eliminate Wadler-style space leaks through sum
 types. Would it be worth the complexity cost though?

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