SpecConstr needs two runs when one should suffice
This is a spinoff of #14844, which is a spinoff 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 (n1) (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 (n1) (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.