SpecConstr creates redundant many specialisations?
While looking at #17619 (closed) I noticed that SpecConstr appears to be producing more than one specialisation/rule for each call pattern. Specifically, when looking at output from this trace:
@@ -1738,7 +1738,8 @@ spec_one env fn arg_bndrs body (call_pat@(qvars, pats), rule_number)
rule = mkRule this_mod True {- Auto -} True {- Local -}
rule_name inline_act fn_name qvars pats rule_rhs
-- See Note [Transfer activation]
- ; return (spec_usg, OS { os_pat = call_pat, os_rule = rule
+ ; pprTrace "sc-rule" (ppr rule) $
+ return (spec_usg, OS { os_pat = call_pat, os_rule = rule
, os_id = spec_id
, os_rhs = spec_rhs }) }
I noticed three distinct rules emitted of the form (up to alpha renaming):
1 sc-rule
7464 "SC:$weerr0" [2]
1 ┊ ┊ forall (sc_s3W0 :: Int#)
2 ┊ ┊ ┊ ┊ ┊ ┊(sc_s3W1 :: Int#)
3 ┊ ┊ ┊ ┊ ┊ ┊(sc_s3W2 :: Set (ErrorItem (Token [Char])))
4 ┊ ┊ ┊ ┊ ┊ ┊(sc_s3W3 :: Set (ErrorItem (Token [Char]))).
5 ┊ ┊ ┊ $weerr_Xu (TrivialError
6 ┊ ┊ ┊ ┊ ┊ ┊ ┊ ┊ ┊ ┊@ [Char]
7 ┊ ┊ ┊ ┊ ┊ ┊ ┊ ┊ ┊ ┊@ ()
8 ┊ ┊ ┊ ┊ ┊ ┊ ┊ ┊ ┊ ┊(I# sc_s3W0)
9 ┊ ┊ ┊ ┊ ┊ ┊ ┊ ┊ ┊ ┊lvl_s2Zq
10 ┊ ┊ ┊ ┊ ┊ ┊ ┊ ┊ ┊ ┊(Bin
11 ┊ ┊ ┊ ┊ ┊ ┊ ┊ ┊ ┊ ┊ ┊ @ (ErrorItem (Token [Char])) sc_s3W1 lvl_s3l6 sc_s3W2 sc_s3W3))
12 ┊ ┊ ┊ = jump $s$weerr_s3W9 sc_s3W0 sc_s3W1 sc_s3W2 sc_s3W3