Skip to content
GitLab
Projects Groups Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
  • Sign in / Register
  • GHC GHC
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Locked Files
  • Issues 5,242
    • Issues 5,242
    • List
    • Boards
    • Service Desk
    • Milestones
    • Iterations
  • Merge requests 567
    • Merge requests 567
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
    • Test Cases
  • Deployments
    • Deployments
    • Releases
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Code review
    • Insights
    • Issue
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • Glasgow Haskell CompilerGlasgow Haskell Compiler
  • GHCGHC
  • Issues
  • #2598
Closed
Open
Issue created Sep 16, 2008 by Simon Peyton Jones@simonpjDeveloper

Avoid excessive specialisation in SpecConstr

This ticket captures an email thread so it doesn't get lost.

Consider this (from haddock/src/Haddock/Backends/Hoogle.hs):

dropComment (' ':'-':'-':' ':_) = []
dropComment (x:xs) = x : dropComment xs
dropComment [] = []

This desugars thus:

dropComment xs
  = case xs of
      (C# x1 : xs1) ->
        case x1 of
          ' '# ->
             case xs1 of
               (C# x2:xs2) ->
                 case x2 of
                   '-' -> ....
                   DEFAULT -> dropComment (C# x2 : xs2)
          DEFAULT -> ...
       [] -> ...

I have elided the branches that are less interesting, and I have done a bit of multi-level pattern matching to save space.

The thing to notice is this: at the recursive call, we know that the argument is a cons, with C# at the front. So SpecConstr dutifully creates a specialized version. And similarly for each subsequent character! Indeed, if the match fails after matching (' ': '-' : ) prefix, the recursive call even knows that the first char is '-'!

Hence we get as many specializations as we have characters in the input match.

So SpecConstr is behaving as expected. Can anyone think of a heuristic to squash this behavior? At the moment we take the first N specializations and then stop. One heuristic might be "if there are lots of recursive calls, don't specialize". But that is very close to "if there are lots of specializations, drop some". Mind you, perhaps we should be more vigorous still: "if there are more than N, don't do any" on the grounds that randomly choosing the first few is unlikely to be useful.

Any thoughts?

Trac metadata
Trac field Value
Version 6.8.3
Type FeatureRequest
TypeOfFailure OtherFailure
Priority normal
Resolution Unresolved
Component Compiler
Test case
Differential revisions
BlockedBy
Related
Blocking
CC
Operating system Unknown
Architecture Unknown
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
Time tracking