Skip to content
GitLab
Projects Groups Topics Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
  • Register
  • Sign in
  • GHC GHC
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributor statistics
    • Graph
    • Compare revisions
    • Locked files
  • Issues 5.5k
    • Issues 5.5k
    • List
    • Boards
    • Service Desk
    • Milestones
    • Iterations
  • Merge requests 633
    • Merge requests 633
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Artifacts
    • Schedules
    • Test cases
  • Deployments
    • Deployments
    • Releases
  • Analytics
    • Analytics
    • 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
  • Merge requests
  • !4557

Improvements to DmdAnal and WorkWrap

  • Review changes

  • Download
  • Patches
  • Plain diff
Closed Sebastian Graf requested to merge wip/sgraf-dmdanal-stuff into master Dec 02, 2020
  • Overview 34
  • Commits 2
  • Pipelines 11
  • Changes 16

This MR contains two commits: One that fixes #18971 (closed) and the other fixing #18982 (closed). The fix for the former is trivial, I'll focus for the fix on the latter.

DmdAnal + WorkWrap: Unbox constructors with existentials (#18982 (closed))

WorkWrap: Unbox constructors with existentials (#18982 (closed))

Consider

data Ex where
  Ex :: e -> Int -> Ex

f :: Ex -> Int
f (Ex e n) = e `seq` n + 1

Worker/wrapper should build the following worker for f:

$wf :: forall e. e -> Int# -> Int#
$wf e n = e `seq` n +# 1#

But previously it didn't, because Ex binds an existential. This patch lifts that condition. That entailed having to instantiate existential binders in GHC.Core.Opt.WorkWrap.Utils.mkWWstr via GHC.Core.Utils.dataConRepFSInstPat, requiring a bit of a refactoring around what is now DataConPatContext.

CPR W/W still won't unbox DataCons with existentials. See Note [Which types are unboxed?] for details.

I also refactored the various tyCon*DataCon(s)_maybe functions in GHC.Core.TyCon, deleting some of them which are no longer needed (isDataProductType_maybe and isDataSumType_maybe). I cleaned up a couple of call sites, some of which weren't very explicit about whether they cared for existentials or not.

The test output of T18013 changed, because we now unbox the Rule data type. Its constructor carries existential state and will be w/w'd now. In the particular example, the worker functions inlines right back into the wrapper, which then unnecessarily has a (quite big) stable unfolding. I think this kind of fallout is inevitable; see also Note [Don't w/w inline small non-loop-breaker things].

There's a new regression test case T18982. Fixes #18982 (closed) and #18971 (closed).

Edited Dec 23, 2020 by Sebastian Graf
Assignee
Assign to
Reviewers
Request review from
Time tracking
Source branch: wip/sgraf-dmdanal-stuff