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,392
    • Issues 4,392
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
    • Iterations
  • Merge Requests 374
    • Merge Requests 374
  • Requirements
    • Requirements
    • List
  • CI / CD
    • CI / CD
    • Pipelines
    • Jobs
    • Schedules
    • Test Cases
  • Operations
    • Operations
    • Incidents
    • Environments
  • Analytics
    • Analytics
    • CI / CD
    • Code Review
    • Insights
    • Issue
    • Repository
    • Value Stream
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Members
    • Members
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • Glasgow Haskell Compiler
  • GHCGHC
  • Issues
  • #13589

Closed
Open
Opened Apr 18, 2017 by Ben Gamari@bgamari🐢Maintainer

Possible inconsistency in CSE's treatment of NOINLINE

While debugging #13535 I noticed the following inconsistency in CSE:

Note [CSE for INLINE and NOINLINE] states that we need to take care when adding expressions bound to binders with inline pragmas to the CSEnv. To see why, consider the following,

{-# NOINLINE bar #-}
bar = <rhs>     -- Same rhs as foo

foo = <rhs>

Given this program, we need to avoid producing foo = bar since doing so would mean that we would lose the ability to inline foo's original RHS.

The note then goes on to give the following rule,

We should not add

<rhs> :-> bar

to the CSEnv if bar has any constraints on when it can inline; that is, if its 'activation' not always active. Otherwise we might replace <rhs> by bar, and then later be unable to see that it really was <rhs>.

This rule is implemented in noCSE with,

  not (isAlwaysActive (idInlineActivation id))

However, it's quite unclear to me that this rule avoids the issue we set out to solve. Afterall, NOINLINE bar is always active, but it still means that rewriting foo to foo=bar would lose us the ability to see foo's original RHS.

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