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,273
    • Issues 4,273
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
    • Iterations
  • Merge Requests 413
    • Merge Requests 413
  • 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
  • #2078

Closed
Open
Opened Feb 06, 2008 by Simon Peyton Jones@simonpjDeveloper

INLINE and strictness

Consider this code

module A where
  {-# INLINE [0] foo #-}
  {#- RULE foo (reverse xs) = xs #-}
  foo xs = reverse $ xs

module B where
  import A( foo )
  g b ys = foo (case b of 
                  True -> reverse ys
                  False -> ys)

  h xs = map foo xs

At the moment the body of foo is not optimised at all, because it's going to be inlined. But that means that

  • The foo executed by the map in h is very inefficient, because it actually calls $ etc.
  • The strictness analyser doesn't see that foo is strict, because again the $ gets in the way. So the rule for foo does not match in the RHS of g. (If foo were strict, we'd push the call to foo inside the case branches.)

For both reasons it'd be better to

  • Retain the original RHS of foo for inlining purposes
  • But otherwise optimise foo normally, so that if it is not inlined, we get the efficient version, and so that strictness analysis does the right thing.

Hmm. Maybe INLINE should turn into a RULE, rather than (as now) a Note in Core?

Anyway, this ticket is to make sure I don't forget this point.

Trac metadata
Trac field Value
Version 6.8.2
Type Bug
TypeOfFailure OtherFailure
Priority normal
Resolution Unresolved
Component Compiler
Test case
Differential revisions
BlockedBy
Related
Blocking
CC ndp@cse.unsw.edu.au
Operating system Unknown
Architecture Unknown
Assignee
Assign to
7.6.1
Milestone
7.6.1
Assign milestone
Time tracking
None
Due date
None
Reference: ghc/ghc#2078