[GHC] #14951: SpecContsr needs two runs when one should suffice

[GHC]

#14951: SpecContsr needs two runs when one should suffice
-------------------------------------+-------------------------------------
           Reporter:  nomeata        |             Owner:  (none)
               Type:  task           |            Status:  new
           Priority:  normal         |         Milestone:
          Component:  Compiler       |           Version:  8.2.2
           Keywords:  SpecConstr     |  Operating System:  Unknown/Multiple
       Architecture:                 |   Type of failure:  None/Unknown
  Unknown/Multiple                   |
          Test Case:                 |        Blocked By:
           Blocking:                 |   Related Tickets:  #14844
Differential Rev(s):                 |         Wiki Page:
-------------------------------------+-------------------------------------
 This is a spin-off of #14844, which is a spin-off of #14068, but applies
 on its own.

 Consider this code:
 {{{
 module T14844Example (topLvl) where

 topLvl large = (bar1, bar2, foo)
   where
     foo :: Integer -> (a -> b -> Bool) -> (a,b) -> Bool
     foo 0 _ _ = False
     foo s f t = l s' t
        where
          l 0 t = False
          l 1 t = case t of (x,y) -> f x y
          l n (x,y) = l (n-1) (x,y)
          s' = large s

     bar1 :: Integer -> (a -> b -> Bool) -> a -> b -> Bool
     bar1 s f x y = foo s f (x,y)

     bar2 :: Integer ->  (a -> b -> Bool) -> a -> b -> Bool
     bar2 s f x y = foo (s + 1) f (x,y)
 }}}

 Status quo: `l` gets specialized, because of the two call patterns `s' t0`
 and `(s-1) (x,y)`, the second one is interesting *and* its second argument
 gets scrutinized (the `scu_occs` field reports `ScrutOcc` for `t`). But
 `foo` does not get specialized: It does have an interesting call pattern,
 but `scu_occs` reports `UnkOcc`, because `foo`’s parameters are just
 passed to `t`.

 But: When we decide to !SpecConstr `l`, we know that one of the calls to
 `l` is of the shape `s' t0`. This is a boring call, and we do not create a
 specialization for it. But we create a specialization for `l` using the
 the other call pattern. This means we know that it would be beneficial if
 `t0` were a constructor. So can we, at this point, decide to include `t0 ↦
 ScrutOcc` in `scu_occs`?

 First experiments look good, so I am working on this.

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