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,390
    • Issues 4,390
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
    • Iterations
  • Merge Requests 373
    • Merge Requests 373
  • 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
  • #9020

Closed
Open
Opened Apr 22, 2014 by Simon Peyton Jones@simonpjDeveloper

Massive blowup of code size on trivial program

The test simplCore/should_compile/simpl015 was leading to massive compile times. This is weird: it looks like:

main = do { return ()
          ; return ()
          ... hundreds more times ...
          ; return () }

It turns out that the cause was over-eager eta-expansion. Each return () gives a top-level PAP thus

lvl17 :: IO ()
lvl17 = returnIO ()

But these definitions are then eta-expanded, thus:

lvl17 = ((\eta. returnIO () |> sym g) eta) |> g

    where   g :: State# RealWorld -> (# State# RealWorld, () #)
                 ~
                 IO ()

Now in general it makes sense to eta-expand through newtypes (as is done here), because it exposes more lambadas. But it really doesn't make sense to eta-expand a PAP like this.

Fortunately the fix is easy: use exprArity rather than manifestArity in SimplUtils.tryEtaExpandRhs.

The effect on simpl015 is dramatic: compiler allocation drops from 6.6G to 812M; and residency drops from 1.8G to 45M.

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