[commit: ghc] wip/spj-early-inline: Inline data constructor wrappers in phase 2 only (2e077cc)

git at git.haskell.org git at git.haskell.org
Fri Feb 17 16:28:16 UTC 2017


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

On branch  : wip/spj-early-inline
Link       : http://ghc.haskell.org/trac/ghc/changeset/2e077ccc736a0b2a622b7f42b7929966bddb4ded/ghc

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

commit 2e077ccc736a0b2a622b7f42b7929966bddb4ded
Author: Simon Peyton Jones <simonpj at microsoft.com>
Date:   Tue Feb 14 13:49:13 2017 +0000

    Inline data constructor wrappers in phase 2 only
    
    This patch prepares for my upcoming early-inlining patch. It arranges
    that data constructor wrappers are not inlined until Phase 2 (the
    first of the "normal" phases.)  That gives rules a chance to fire
    in the InitialPhase (aka "gentle").
    
    This has been a bit of a problem for a while, so it's nice to have
    a fix.  It should make no difference immediately, becuase currently
    nothing is inlined in the InitialPhase anyway.


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

2e077ccc736a0b2a622b7f42b7929966bddb4ded
 compiler/basicTypes/MkId.hs | 22 ++++++++++++++++++++--
 1 file changed, 20 insertions(+), 2 deletions(-)

diff --git a/compiler/basicTypes/MkId.hs b/compiler/basicTypes/MkId.hs
index 65860d9..2b18186 100644
--- a/compiler/basicTypes/MkId.hs
+++ b/compiler/basicTypes/MkId.hs
@@ -518,7 +518,7 @@ mkDataConRep dflags fam_envs wrap_name mb_bangs data_con
                          `setArityInfo`         wrap_arity
                              -- It's important to specify the arity, so that partial
                              -- applications are treated as values
-                         `setInlinePragInfo`    alwaysInlinePragma
+                         `setInlinePragInfo`    wrap_prag
                          `setUnfoldingInfo`     wrap_unf
                          `setStrictnessInfo`    wrap_sig
                              -- We need to get the CAF info right here because TidyPgm
@@ -527,10 +527,15 @@ mkDataConRep dflags fam_envs wrap_name mb_bangs data_con
                          `setNeverLevPoly`      wrap_ty
 
              wrap_sig = mkClosedStrictSig wrap_arg_dmds (dataConCPR data_con)
+
              wrap_arg_dmds = map mk_dmd arg_ibangs
              mk_dmd str | isBanged str = evalDmd
                         | otherwise           = topDmd
 
+             wrap_prag = alwaysInlinePragma `setInlinePragmaActivation`
+                         ActiveAfter NoSourceText 2
+                         -- See Note [Activation for data constructor wrappers]
+
              -- The wrapper will usually be inlined (see wrap_unf), so its
              -- strictness and CPR info is usually irrelevant. But this is
              -- not always the case; GHC may choose not to inline it. In
@@ -620,7 +625,20 @@ mkDataConRep dflags fam_envs wrap_name mb_bangs data_con
            ; expr <- mk_rep_app prs (mkVarApps con_app rep_ids)
            ; return (unbox_fn expr) }
 
-{-
+{- Note [Activation for data constructor wrappers]
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+The Activation on a data constructor wrapper allows it to inline in
+Phase 2 and later (1, 0).  But not in the InitialPhase.  That gives
+rewrite rules a chance to fire (in the InitialPhase) if they mention
+a data constructor on the left
+   RULE "foo"  f (K a b) = ...
+Since the LHS of rules are simplified with InitialPhase, we won't
+inline the wrapper on the LHS either.
+
+People have asked for this before, but now that even the InitialPhase
+does some inlining, it has become important.
+
+
 Note [Bangs on imported data constructors]
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 



More information about the ghc-commits mailing list