[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
      Resolution:                    |             Keywords:  SpecConstr
Operating System:  Unknown/Multiple  |         Architecture:
                                     |  Unknown/Multiple
 Type of failure:  None/Unknown      |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:  #14844            |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------
Description changed by simonpj:

Old description:

> 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.

New description:

 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
 * `l s' t` and
 * `l (n-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`.

 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#comment:4>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler