Skip to content
GitLab
Projects Groups Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
  • Sign in / Register
  • GHC GHC
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Locked Files
  • Issues 5,249
    • Issues 5,249
    • List
    • Boards
    • Service Desk
    • Milestones
    • Iterations
  • Merge requests 578
    • Merge requests 578
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
    • Test Cases
  • Deployments
    • Deployments
    • Releases
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Code review
    • Insights
    • Issue
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • Glasgow Haskell CompilerGlasgow Haskell Compiler
  • GHCGHC
  • Issues
  • #15840
Closed
Open
Issue created Oct 31, 2018 by Arnaud Spiwack@aspiwackDeveloper

Inline data constructor wrappers very late

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
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
Time tracking