Add INLINE (or at least INLINABLE) pragmas for methods of Ord in ghc-prim

Self-explanatory. Eq already has INLINE on (==) and (/=), and it'd be nice to have it on Ord so that SPECIALIZE pragmas on its methods in user code can fire.

Trac metadata

Trac field	Value
Version	7.6.3
Type	FeatureRequest
TypeOfFailure	OtherFailure
Priority	normal
Resolution	Unresolved
Component	libraries (other)
Test case
Differential revisions
BlockedBy
Related
Blocking
CC
Operating system
Architecture

changed weight to 5

added Tfeature request Trac import labels

Sounds good to me. By all means offer a patch. Worth measuring the effect on binary size, at least as a sanity check.

Simon

is there any argument for inline over inlineable here?

this also *should* be emailed to the haskell libraries mailing list, right?

assigned to @trac-ekmett

Moving over to new owning component 'Core Libraries'.

Trac metadata

Trac field	Value
Component	libraries (other) → Core Libraries

added core libraries label

In commit 4c03791f (libraries/ghc-prim/GHC/Classes.hs):

Author: Simon Peyton Jones <>
Date:   Mon May 12 10:53:09 2014 +0100

    Specialise Eq, Ord, Read, Show at Int, Char, String
    
    These instances are quite common, so it's good to have
    pre-specialised versions available

Trac metadata

Trac field	Value
CC	→ core-libraries-committee@haskell.org

I'm wondering if we should revert the Eq and Ord specialization for String and instead try to have some fun with fusion, doing something much like what we do with foldr2. If I'm not mistaken,

xs == ys = foldr go null xs ys
  where
    go _x _r [] = False
    go  x  r (z:zs)
      | x == z    = r zs
      | otherwise = False

compare xs ys = foldr go (bool LT EQ . null) xs ys
  where
    go _x _r [] = GT
    go  x  r (z:zs) =
      case compare x z of
        EQ -> r zs
        c  -> c

and similarly (carefully) reversing the roles of xs and ys.

Trac metadata

Trac field	Value
TypeOfFailure	OtherFailure → RuntimePerformance

added Pnormal label

mentioned in commit 6b29213f

mentioned in merge request !5367

mentioned in commit 9112dc2d

mentioned in merge request !5368

mentioned in commit 4466ab6e

mentioned in commit 3b19c600

I have created !5367 and !5368 to check whether adding either INLINABLE or INLINE pragmas would trigger any perf tests or other issues. Both patches cause perf regressions in T12545 (+3.3% – +4.1%) which however is notoriously fickle (#19414 (closed) is related).

How do I use the new perf dashboards at https://grafana.gitlab.haskell.org/d/s3PVoM_Mz/ghc-testsuite-performance?orgId=2 to get the numbers for my MRs?

In any case, I'm currently more inclined to go with the INLINABLE pragmas since INLINE pragmas would be more likely to cause compiler perf regressions.

@core-libraries, any thoughts?

I’d like @AndreasK and @fgaz to chime in, since they and I put some thought into current optimization pragma semantics vs intents of programmers. I’d be inclined to ‘inlineable’ but there’s some nuance I often overlook or may be forgetting

INLINABLE is really to allow specialization (and manual inlining with GHC.Exts.inline) of functions for which GHC would not otherwise produce an unfolding. I'm not sure what it does otherwise, but I don't think it encourages inlining.