[commit: ghc] wip/all-inlinable: Always expose unfoldings for overloaded functions. (75cba70)

[git at git.haskell.org]

Repository : ssh://git@git.haskell.org/ghc

On branch  : wip/all-inlinable
Link       : http://ghc.haskell.org/trac/ghc/changeset/75cba70113e47fa4f3e60ab6d18594f7a6dfb1bc/ghc

>---------------------------------------------------------------

commit 75cba70113e47fa4f3e60ab6d18594f7a6dfb1bc
Author: Matthew Pickering <matthewtpickering at gmail.com>
Date:   Sat Aug 6 22:17:09 2016 +0100

    Always expose unfoldings for overloaded functions.
    
    Summary:
    Users expect their overloaded functions to be specialised at call sites,
    however, this is only the case if they are either lucky and GHC chooses to
    include the unfolding or they mark their definition with an INLINABLE pragma.
    This leads to library authors marking all their functions with `INLINABLE` (or
    more accurately `INLINE`) so they ensure that downstream consumers pay no cost
    for their abstraction.
    
    A more sensible default is to do this job for the library author and give more
    predictable guarantees about specialisation.
    
    Empirically, I compiled a selection of 1150 packages with (a similar) patch applied. The total size of the interface files before the patch was 519mb and after 634mb. On modern machines, I think this increase is justified for the result.
    
    Reviewers: simonpj, austin, bgamari
    
    Subscribers: thomie
    
    Differential Revision: https://phabricator.haskell.org/D2929
    
    Conflicts:
    	compiler/specialise/Specialise.hs


>---------------------------------------------------------------

75cba70113e47fa4f3e60ab6d18594f7a6dfb1bc
 compiler/main/TidyPgm.hs          | 7 ++++++-
 compiler/specialise/Specialise.hs | 6 +++++-
 2 files changed, 11 insertions(+), 2 deletions(-)

diff --git a/compiler/main/TidyPgm.hs b/compiler/main/TidyPgm.hs
index 8f2e334..6bbd556 100644
--- a/compiler/main/TidyPgm.hs
+++ b/compiler/main/TidyPgm.hs
@@ -58,6 +58,7 @@ import ErrUtils (Severity(..))
 import Outputable
 import SrcLoc
 import qualified ErrUtils as Err
+import TcType           ( isOverloadedTy )
 
 import Control.Monad
 import Data.Function
@@ -726,6 +727,7 @@ addExternal expose_all id = (new_needed_ids, show_unfold)
     never_active   = isNeverActive (inlinePragmaActivation (inlinePragInfo idinfo))
     loop_breaker   = isStrongLoopBreaker (occInfo idinfo)
     bottoming_fn   = isBottomingSig (strictnessInfo idinfo)
+    is_overloaded  = isOverloadedTy (idType id)
 
         -- Stuff to do with the Id's unfolding
         -- We leave the unfolding there even if there is a worker
@@ -737,11 +739,14 @@ addExternal expose_all id = (new_needed_ids, show_unfold)
 
        || isStableSource src     -- Always expose things whose
                                  -- source is an inline rule
-
        || not (bottoming_fn      -- No need to inline bottom functions
            || never_active       -- Or ones that say not to
            || loop_breaker       -- Or that are loop breakers
            || neverUnfoldGuidance guidance)
+       || (if is_overloaded
+            then pprTrace "ADDITIONAL UNFOLDING:" (ppr id) True
+            else False)           -- Always expose overloaded things so that
+                                 -- they can be specialised at call sites.
     show_unfolding (DFunUnfolding {}) = True
     show_unfolding _                  = False
 
diff --git a/compiler/specialise/Specialise.hs b/compiler/specialise/Specialise.hs
index 33ce1ac..159fbf7 100644
--- a/compiler/specialise/Specialise.hs
+++ b/compiler/specialise/Specialise.hs
@@ -753,13 +753,17 @@ wantSpecImport dflags unf
      NoUnfolding      -> False
      OtherCon {}      -> False
      DFunUnfolding {} -> True
-     CoreUnfolding { uf_src = src, uf_guidance = _guidance }
+     CoreUnfolding { uf_src = src, uf_guidance = _guidance } -> True
+
+{-
        | gopt Opt_SpecialiseAggressively dflags -> True
        | isStableSource src -> True
                -- Specialise even INLINE things; it hasn't inlined yet,
                -- so perhaps it never will.  Moreover it may have calls
                -- inside it that we want to specialise
        | otherwise -> False    -- Stable, not INLINE, hence INLINEABLE
+       | otherwise -> False    -- Stable, not INLINE, hence INLINABLE
+-}
 
 {- Note [Warning about missed specialisations]
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~