This came up in the context of the implementation of linear types, where more data constructors have wrapper. But this should be of more general use. I want to share this in case someone can find an objection to this approach.

Currently, writing a RULE involving a data constructor with a wrapper is perilous: the wrapper will be inlined in phase 2, probably before the RULE is even triggered (necessarily if the RULE only runs in phase 1).

I want to remedy this situation. This proposal is mainly from Simon Peyton Jones, any misrepresentation is, of course, my own.

The proposal is to inline all data constructor wrappers in phase 0. After all the RULE business has been dealt with. If we do that, we need to be quite careful about case-of-know-constructor:

In

case $WK u of { K x -> e; … }

$WK wouldn't unfold until very late. But we don't want the case expression to be blocked! Otherwise we may, for instance, prevent the function's size to be small enough to be inlined. Hence a maybe some rules will not trigger. That would not be acceptable.

Fortunately, in order to decide whether case-of-known-constructor can perform, the simplifier calls exprIsConApp_maybe. Also fortunate is that in the situation above, we really don't care about any RULE stuff (at least not in relation with K). So what we can do is make exprIsConApp_maybe a bit smarter and teach it to see through data constructor wrappers.

Let's take an unpacking wrapper as an example:

data T = MkT {-# UNPACK #-} !(Int, Bool)

$WMkT p = case p of (i,b) -> MkT i b

We have to see that $WMkT u is a constructor application. Hence we need to be able to peek through cases. We also need to be able to witness that we have done so. So the type of exprIsConApp_maybe would change from

exprIsConApp_maybe :: InScopeEnv -> CoreExpr -> Maybe (DataCon, [Type], [CoreExpr])

to

exprIsConApp_maybe :: InScopeEnv -> CoreExpr -> Maybe ([Float],DataCon, [Type], [CoreExpr])

Where Float-s are lets or cases with a single alternative (much like in the FloatOut pass).

We then need to change case-of-known-constructor to also perform case-of-lets and case-of-cases when such floats are found.

In summary: data constructor wrappers would be inlined in phase 0, except when they can trigger a case-of-known constructor, in which case they would be inlined immediately.

Does anyone sees something which could go wrong with this plan?

Trac metadata

Trac field	Value
Version	8.7
Type	FeatureRequest
TypeOfFailure	OtherFailure
Priority	normal
Resolution	Unresolved
Component	Compiler
Test case
Differential revisions
BlockedBy
Related
Blocking
CC
Operating system
Architecture