#7360: Case-of-identical-alts optimisation fails abjectly
    Reporter:  simonpj           |       Owner:                  
        Type:  bug               |      Status:  new             
    Priority:  normal            |   Milestone:                  
   Component:  Compiler          |     Version:  7.6.1           
    Keywords:                    |          Os:  Unknown/Multiple
Architecture:  Unknown/Multiple  |     Failure:  None/Unknown    
  Difficulty:  Unknown           |    Testcase:                  
   Blockedby:                    |    Blocking:                  
     Related:                    |  

Comment(by simonpj):

 I was very surprised to see this but you are absolutely right.  The reason
 the occurrence info does not show the alternative's binders as dead shows
 up in `Simplify.simplAlt`.  Look at the call to `zapBndrOccInfo`,
 controlled by the boolean `keep_occ_info`.  Notice that `keep_occ_info` is
 false if the scrutinee is a variable, which it usually is.   This is
 enough to defeat the optimisation.

 The reason is described in `Note [zapOccInfo]` in `Simplify.lhs`.  If we
   case x of { C a b -> ....case x of { C p q -> p }.... }
 Now, `a` and `b` are not mentioned, and are hence dead.  But if we were to
 optimise the inner case, we'd reduce
     case x of { C p q -> p }   ===>    a
 and now `a` is alive. Moreover `mkCase1` is applied use '''after''' the
 alternative has been simplified, so now it in fact looks like
   case x of { C a b -> ....a.... }
 That's why a's occurrence info is zapped: it might not be dead any more.

 But in fact the occurrence analyser goes to great trouble (the "binder-
 swap" optimisation) to ensure that if the scrutinee is a variable, we
 replace its uses in the alternatives with the case-binder.  So the
 occurrence analyser will produce this
   case x of y { C a b -> ....case y of { C p q -> p }.... }
 So we really don't need to take the scrutinee into account.

 I think I see how to ''both'' simplify the code ''and'' make the
 optimisation work again. I need enough time to do some comparative nofib
 runs to make sure I hvae not messed up, though.

 Thanks for pointing this out.


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

Glasgow-haskell-bugs mailing list

Reply via email to