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,320
    • Issues 4,320
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
    • Iterations
  • Merge Requests 359
    • Merge Requests 359
  • 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
  • #3526

Closed
Open
Opened Sep 18, 2009 by bos@trac-bos

Inliner behaviour with instances is confusing

I have a fairly simple typeclass:

class Variate a where
    uniform :: Gen s -> ST s a

With instances like this:

instance Variate Int8 where
    uniform = f where f = uniform1 fromIntegral
                      {-# INLINE f #-}

uniform1 :: (Word32 -> a) -> Gen s -> ST s a
uniform1 f gen = do
  i <- uniformWord32 gen
  return $! f i
{-# INLINE uniform1 #-}

Notice the peculiar form of the instance definition. I had to write the above instead of the more intuitive form:

instance Variate Int8 where
    uniform = uniform1 fromIntegral
    {-# INLINE uniform #-}

With the more obvious form, GHC's inliner didn't fire at all for this, and I was unable to tell why. It was Duncan who suggested the more convoluted instance above. The result is about a 3x performance difference sometimes, so this has a noticeable effect.

I'm not completely sure that this is a bug, but I don't know how to describe why one form works and the other doesn't, so the compiler's behaviour is surprising to me.

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