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
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
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
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,
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).
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.
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.