[GHC] #11731: Simplifier: Inlining trivial let can lose sharing

[GHC]

#11731: Simplifier: Inlining trivial let can lose sharing
-------------------------------------+-------------------------------------
        Reporter:  nomeata           |                Owner:
            Type:  bug               |               Status:  patch
        Priority:  normal            |            Milestone:
       Component:  Compiler          |              Version:  8.1
      Resolution:                    |             Keywords:
Operating System:  Unknown/Multiple  |         Architecture:
                                     |  Unknown/Multiple
 Type of failure:  None/Unknown      |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):  Phab:D2064
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by nomeata):

 I think I nailed it. With the above change, demand information becomes
 something that we should try to keep hold on. But we don’t:

 {{{#!hs
 simplExprF1 env expr@(Lam {}) cont
   = simplLam env zapped_bndrs body cont
         -- The main issue here is under-saturated lambdas
         --   (\x1. \x2. e) arg1
         -- Here x1 might have "occurs-once" occ-info, because occ-info
         -- is computed assuming that a group of lambdas is applied
         -- all at once.  If there are too few args, we must zap the
         -- occ-info, UNLESS the remaining binders are one-shot
   where
     (bndrs, body) = collectBinders expr
     zapped_bndrs | need_to_zap = map zap bndrs
                  | otherwise   = bndrs

     need_to_zap = any zappable_bndr (drop n_args bndrs)
     n_args = countArgs cont
         -- NB: countArgs counts all the args (incl type args)
         -- and likewise drop counts all binders (incl type lambdas)

     zappable_bndr b = isId b && not (isOneShotBndr b)
     zap b | isTyVar b = b
           | otherwise = zapLamIdInfo b
 }}}

 Here, we would remove the demand information from the parameters of a top-
 level function (unless all of them happen to be one-shot-binders). I don’t
 fully understand the comment here. Does "occurs-once" refer to occurence
 information only? But `zapLamInfo` in `IdInfo` also removes Demand
 information...sometimes.

 This looks delicate. Why does demand information (which is calculated from
 the body of the lamda, not how it is being used) need to be zapped in
 `zapLamInfo` at all?

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