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,334
    • Issues 4,334
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
    • Iterations
  • Merge Requests 371
    • Merge Requests 371
  • 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
  • #4299

Closed
Open
Opened Sep 09, 2010 by Simon Marlow@simonmarDeveloper

a less forceful INLINE pragma

The INLINE pragmas currently does two things:

  1. it saves an unoptimised definition of the function in the interface file, and
  2. it unfolds the definition at (almost) every call site, before optimising it further in situ.

I'm proposing that we have a variant of the INLINE pragma that does (1) without necessarily unfolding the definition at every call site. GHC's simplifier already has some well-tuned heuristics for deciding whether to inline something or not based on information about the context, and when we use INLINE we bypass all this and potentially end up with unnecessary code bloat and maybe even a loss of performance in some cases.

If we had an INLINEABLE pragma that did (1) without forcing (2), then the decision about whether to inline or not is deferred to the call site, where the user can decide how they want to trade off code size against speed. Right now the user doesn't get to decide - the library writer does.

Trac metadata
Trac field Value
Version 6.12.3
Type FeatureRequest
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#4299