Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
  • Sign in / Register
GHC
GHC
  • Project overview
    • Project overview
    • Details
    • Activity
    • Releases
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Locked Files
  • Issues 4,260
    • Issues 4,260
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
    • Iterations
  • Merge Requests 398
    • Merge Requests 398
  • Requirements
    • Requirements
    • List
  • CI / CD
    • CI / CD
    • Pipelines
    • Jobs
    • Schedules
  • Security & Compliance
    • Security & Compliance
    • Dependency List
    • License Compliance
  • Operations
    • Operations
    • Incidents
    • Environments
  • Analytics
    • Analytics
    • CI / CD
    • Code Review
    • Insights
    • Issue
    • Repository
    • Value Stream
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Members
    • Members
  • Collapse sidebar
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
  • Glasgow Haskell Compiler
  • GHCGHC
  • Issues
  • #15001

Closed
Open
Opened Apr 04, 2018 by Sebastian Graf@sgraf812Developer

Add strict product field demands to lambda binders

This is a follow-up on the first improvement in [D4244#126311].

Consider the following two functions with identical semantics:

module Foo where

{-# LANGUAGE BangPatterns #-}
data Complex a = !a :+ !a

foo :: Complex Double -> Int -> Complex Double
foo !x 0 = x
foo (a :+ b) _ = b :+ a

bar :: Complex Double -> Int -> Complex Double
bar x 0 = x
bar (a :+ b) _ = b :+ a

In the corresponding simplified Core, x gets strictness S(SS) for foo, but only S for bar. We could do better by looking at xs type and see that its a product type with strict fields.

This is because currently only case binders get special treatment for strict product fields through addDataConStrictness.

This ticket tracks if the same is worthwhile for lambda binders, as in bar above. Note that intuitively, this shouldn't make any difference because when we eventually unleash an S demand on a Complex constructor, we add seqDmd on strict fields anyway, amounting to S(SS). So this is only a matter of recording things early because some parts of the analysis code might not be smart enough to add strict field demands by themselves.

Also note that this doesn't touch impliciations on usage analysis at all, where unleashing the same seqDmd twice might mean we accidentally make some product field lose its single-entrieness.

Trac metadata
Trac field Value
Version 8.5
Type Task
TypeOfFailure OtherFailure
Priority normal
Resolution Unresolved
Component Compiler
Test case
Differential revisions D4244
BlockedBy
Related
Blocking
CC simonpj
Operating system
Architecture
Assignee
Assign to
⊥
Milestone
⊥
Assign milestone
Time tracking
None
Due date
None
Reference: ghc/ghc#15001