Need NoSpecConstr which has been nuked in GHC-9.0
Summary
We use stream fusion heavily in https://github.com/composewell/streamly . One of the critical optimizations that we depend on is SpecConstr. We use the SPEC argument to force spec constructor optimization. To have a better control over it we also need a way to stop SpecConstr optimization from occurring in some specific cases.
Though we absolutely need SpecConstr optimization in the loop we do not want it to happen for a particular type (which is a list type in this case here https://github.com/composewell/streamly/blob/05613cd6cfd35f442c62116a435bd80fa51ae69c/src/Streamly/Internal/Data/Stream/StreamD.hs#L956) because a recursive SpecConstr on that type leads to a huge code bloat and unacceptable compile time. Currently SpecConstr optimization provides no control to avoid it for certain cases, the only workaround we had for this was NoSpecConstr which has been nuked in GHC-9.0.
The change was brought via the issue #13681. The issue author seems to have cautioned against removing NoSpecConstr. Quoting from the issue:
It isn't clear to me why it is ok to get rid of
NoSpecConstr(which prevents SpecConstr firing) either.
It doesn't seem to be currently used but I guess we could add a
NOSPECdatatype similarly toSPECif necessary.
First of all a NOSPEC would not be able to do what we want as it cannot give us control to disable it for a specific argument/type. We will need a more advanced mechanism to allow that. Second, any such replacement should be introduced before removing what we have already.
I would request you to please revert MR 3138 (!3138 (closed)) until an equivalent facility is implemented. We will have a tough time if we do not have this or an equivalent way to control SpecConstr.
Environment
- GHC version used: ghc-9.0.1-rc1
Copying people from the issue and MR @hsyl20 @bgamari @mpickering