[GHC] #8900: Strictness analysis regression

[GHC]

#8900: Strictness analysis regression
--------------------------------------------+------------------------------
        Reporter:  tibbe                    |            Owner:
            Type:  bug                      |           Status:  new
        Priority:  normal                   |        Milestone:
       Component:  Compiler                 |          Version:  7.8.1-rc2
      Resolution:                           |         Keywords:
Operating System:  MacOS X                  |     Architecture:  x86_64
 Type of failure:  Runtime performance bug  |  (amd64)
       Test Case:                           |       Difficulty:  Unknown
        Blocking:                           |       Blocked By:
                                            |  Related Tickets:
--------------------------------------------+------------------------------

Comment (by simonpj):

 Johan, the "extra case" comes from commit
 28d9a03253e8fd613667526a170b684f2017d299, whose comment says
 {{{
     Make CaseElim a bit less aggressive

     See Note [Case elimination: lifted case]:

     We used to do case elimination if
             (c) the scrutinee is a variable and 'x' is used strictly
     But that changes
         case x of { _ -> error "bad" }
         --> error "bad"
     which is very puzzling if 'x' is later bound to (error "good").
     Where the order of evaluation is specified (via seq or case)
     we should respect it.
 }}}
 And indeed that's a good point.  `Note [Case binder next]` in
 `Simplify.lhs` is relevant here.

 You point out that `$wpoly_go` is strict in its last arg, so it really is
 "next".  I wonder how picky we want to be. Consider
 {{{
 case x of y -> g (error "uk") y
 }}}
 and suppose that g is strict in both arguments.  Would it be ok to drop
 the case?  Then we might get `error "uk"` (if `g` evaluated its first arg
 first) rather than any error arising from `x`?  Probably yes, I guess.

 Indeed maybe the change is just wrong, or at least over-conservative.
 According to our paper "A semantics of imprecise exceptions" it is ok.  I
 don't think anyone actually reported a bug.  So maybe we should revert to
 the ghc 7.6 behaviour?

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