From ab4c27e917e959778726b82fa6cc8b80eca28e74 Mon Sep 17 00:00:00 2001 From: Simon Peyton Jones Date: Fri, 29 Aug 2014 15:16:16 +0100 Subject: Comments, white space, and rename "InlineRule" to "stable unfolding" The "InlineRule" is gone now, so this is just making the comments line up with the code. A function does change its name though: updModeForInlineRules --> updModeForStableUnfoldings --- compiler/simplCore/OccurAnal.lhs | 10 +++---- compiler/simplCore/SimplUtils.lhs | 62 +++++++++++++++++++-------------------- compiler/simplCore/Simplify.lhs | 12 ++++---- compiler/stranal/WorkWrap.lhs | 4 +-- 4 files changed, 44 insertions(+), 44 deletions(-) diff --git a/compiler/simplCore/OccurAnal.lhs b/compiler/simplCore/OccurAnal.lhs index 6456eccd49..7a237c8764 100644 --- a/compiler/simplCore/OccurAnal.lhs +++ b/compiler/simplCore/OccurAnal.lhs @@ -625,13 +625,13 @@ data Details = ND { nd_bndr :: Id -- Binder , nd_rhs :: CoreExpr -- RHS, already occ-analysed - , nd_uds :: UsageDetails -- Usage from RHS, and RULES, and InlineRule unfolding + , nd_uds :: UsageDetails -- Usage from RHS, and RULES, and stable unfoldings -- ignoring phase (ie assuming all are active) -- See Note [Forming Rec groups] , nd_inl :: IdSet -- Free variables of - -- the InlineRule (if present and active) - -- or the RHS (ir no InlineRule) + -- the stable unfolding (if present and active) + -- or the RHS (if not) -- but excluding any RULES -- This is the IdSet that may be used if the Id is inlined @@ -1798,8 +1798,8 @@ tagLamBinders :: UsageDetails -- Of scope -> (UsageDetails, -- Details with binders removed [IdWithOccInfo]) -- Tagged binders -- Used for lambda and case binders --- It copes with the fact that lambda bindings can have InlineRule --- unfoldings, used for join points +-- It copes with the fact that lambda bindings can have a +-- stable unfolding, used for join points tagLamBinders usage binders = usage' `seq` (usage', bndrs') where (usage', bndrs') = mapAccumR tag_lam usage binders diff --git a/compiler/simplCore/SimplUtils.lhs b/compiler/simplCore/SimplUtils.lhs index 941587c878..1cfba43c5e 100644 --- a/compiler/simplCore/SimplUtils.lhs +++ b/compiler/simplCore/SimplUtils.lhs @@ -14,7 +14,7 @@ module SimplUtils ( preInlineUnconditionally, postInlineUnconditionally, activeUnfolding, activeRule, getUnfoldingInRuleMatch, - simplEnvForGHCi, updModeForInlineRules, + simplEnvForGHCi, updModeForStableUnfoldings, -- The continuation type SimplCont(..), DupFlag(..), @@ -542,9 +542,9 @@ simplEnvForGHCi dflags -- Do not do any inlining, in case we expose some unboxed -- tuple stuff that confuses the bytecode interpreter -updModeForInlineRules :: Activation -> SimplifierMode -> SimplifierMode --- See Note [Simplifying inside InlineRules] -updModeForInlineRules inline_rule_act current_mode +updModeForStableUnfoldings :: Activation -> SimplifierMode -> SimplifierMode +-- See Note [Simplifying inside stable unfoldings] +updModeForStableUnfoldings inline_rule_act current_mode = current_mode { sm_phase = phaseFromActivation inline_rule_act , sm_inline = True , sm_eta_expand = False } @@ -572,10 +572,10 @@ Example of why (iii) is important: If we were to inline g into f's inlining, then an importing module would never be able to do f e --> g (g e) ---> RULE fires -because the InlineRule for f has had g inlined into it. +because the stable unfolding for f has had g inlined into it. On the other hand, it is bad not to do ANY inlining into an -InlineRule, because then recursive knots in instance declarations +stable unfolding, because then recursive knots in instance declarations don't get unravelled. However, *sometimes* SimplGently must do no call-site inlining at all @@ -592,9 +592,9 @@ running it, we don't want to use -O2. Indeed, we don't want to inline anything, because the byte-code interpreter might get confused about unboxed tuples and suchlike. -Note [Simplifying inside InlineRules] -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -We must take care with simplification inside InlineRules (which come from +Note [Simplifying inside stable unfoldings] +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +We must take care with simplification inside stable unfoldings (which come from INLINE pragmas). First, consider the following example @@ -605,35 +605,35 @@ First, consider the following example in ...g...g...g...g...g... Now, if that's the ONLY occurrence of f, it might be inlined inside g, and thence copied multiple times when g is inlined. HENCE we treat -any occurrence in an InlineRule as a multiple occurrence, not a single +any occurrence in a stable unfolding as a multiple occurrence, not a single one; see OccurAnal.addRuleUsage. -Second, we do want *do* to some modest rules/inlining stuff in InlineRules, -partly to eliminate senseless crap, and partly to break the recursive knots -generated by instance declarations. +Second, we do want *do* to some modest rules/inlining stuff in stable +unfoldings, partly to eliminate senseless crap, and partly to break +the recursive knots generated by instance declarations. However, suppose we have {-# INLINE f #-} f = meaning "inline f in phases p where activation (p) holds". Then what inlinings/rules can we apply to the copy of captured in -f's InlineRule? Our model is that literally is substituted for +f's stable unfolding? Our model is that literally is substituted for f when it is inlined. So our conservative plan (implemented by -updModeForInlineRules) is this: +updModeForStableUnfoldings) is this: ------------------------------------------------------------- - When simplifying the RHS of an InlineRule, set the phase to the - phase in which the InlineRule first becomes active + When simplifying the RHS of an stable unfolding, set the phase + to the phase in which the stable unfolding first becomes active ------------------------------------------------------------- That ensures that a) Rules/inlinings that *cease* being active before p will - not apply to the InlineRule rhs, consistent with it being + not apply to the stable unfolding, consistent with it being inlined in its *original* form in phase p. b) Rules/inlinings that only become active *after* p will - not apply to the InlineRule rhs, again to be consistent with + not apply to the stable unfolding, again to be consistent with inlining the *original* rhs in phase p. For example, @@ -656,7 +656,7 @@ Similarly, consider and suppose that there are auto-generated specialisations and a strictness wrapper for g. The specialisations get activation AlwaysActive, and the strictness wrapper get activation (ActiveAfter 0). So the strictness -wrepper fails the test and won't be inlined into f's InlineRule. That +wrepper fails the test and won't be inlined into f's stable unfolding. That means f can inline, expose the specialised call to g, so the specialisation rules can fire. @@ -819,7 +819,7 @@ let-float if you inline windowToViewport However, as usual for Gentle mode, do not inline things that are inactive in the intial stages. See Note [Gentle mode]. -Note [InlineRule and preInlineUnconditionally] +Note [Stable unfoldings and preInlineUnconditionally] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Surprisingly, do not pre-inline-unconditionally Ids with INLINE pragmas! Example @@ -838,7 +838,7 @@ we'll lose the opportunity to inline at each of fInt's call sites. The INLINE pragma will only inline when the application is saturated for exactly this reason; and we don't want PreInlineUnconditionally to second-guess it. A live example is Trac #3736. - c.f. Note [InlineRule and postInlineUnconditionally] + c.f. Note [Stable unfoldings and postInlineUnconditionally] Note [Top-level botomming Ids] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -860,7 +860,7 @@ preInlineUnconditionally :: DynFlags -> SimplEnv -> TopLevelFlag -> InId -> InEx -- for unlifted, side-effect-full bindings preInlineUnconditionally dflags env top_lvl bndr rhs | not active = False - | isStableUnfolding (idUnfolding bndr) = False -- Note [InlineRule and preInlineUnconditionally] + | isStableUnfolding (idUnfolding bndr) = False -- Note [Stable unfoldings and preInlineUnconditionally] | isTopLevel top_lvl && isBottomingId bndr = False -- Note [Top-level bottoming Ids] | not (gopt Opt_SimplPreInlining dflags) = False | isCoVar bndr = False -- Note [Do not inline CoVars unconditionally] @@ -976,7 +976,7 @@ postInlineUnconditionally dflags env top_lvl bndr occ_info rhs unfolding | isWeakLoopBreaker occ_info = False -- If it's a loop-breaker of any kind, don't inline -- because it might be referred to "earlier" | isExportedId bndr = False - | isStableUnfolding unfolding = False -- Note [InlineRule and postInlineUnconditionally] + | isStableUnfolding unfolding = False -- Note [Stable unfoldings and postInlineUnconditionally] | isTopLevel top_lvl = False -- Note [Top level and postInlineUnconditionally] | exprIsTrivial rhs = True | otherwise @@ -1069,12 +1069,12 @@ ones that are trivial): * The inliner should inline trivial things at call sites anyway. -Note [InlineRule and postInlineUnconditionally] -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -Do not do postInlineUnconditionally if the Id has an InlineRule, otherwise -we lose the unfolding. Example +Note [Stable unfoldings and postInlineUnconditionally] +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +Do not do postInlineUnconditionally if the Id has an stable unfolding, +otherwise we lose the unfolding. Example - -- f has InlineRule with rhs (e |> co) + -- f has stable unfolding with rhs (e |> co) -- where 'e' is big f = e |> co @@ -1083,10 +1083,10 @@ Then there's a danger we'll optimise to f' = e f = f' |> co -and now postInlineUnconditionally, losing the InlineRule on f. Now f' +and now postInlineUnconditionally, losing the stable unfolding on f. Now f' won't inline because 'e' is too big. - c.f. Note [InlineRule and preInlineUnconditionally] + c.f. Note [Stable unfoldings and preInlineUnconditionally] %************************************************************************ diff --git a/compiler/simplCore/Simplify.lhs b/compiler/simplCore/Simplify.lhs index 49c86a1c19..09a2befe97 100644 --- a/compiler/simplCore/Simplify.lhs +++ b/compiler/simplCore/Simplify.lhs @@ -780,8 +780,8 @@ simplUnfolding env top_lvl id new_rhs unf bottoming = isBottomingId id is_top_lvl = isTopLevel top_lvl act = idInlineActivation id - rule_env = updMode (updModeForInlineRules act) env - -- See Note [Simplifying inside InlineRules] in SimplUtils + rule_env = updMode (updModeForStableUnfoldings act) env + -- See Note [Simplifying inside stable unfoldings] in SimplUtils \end{code} Note [Force bottoming field] @@ -824,9 +824,9 @@ Note [Setting the new unfolding] important: if exprIsConApp says 'yes' for a recursive thing, then we can get into an infinite loop -If there's an InlineRule on a loop breaker, we hang on to the inlining. -It's pretty dodgy, but the user did say 'INLINE'. May need to revisit -this choice. +If there's an stable unfolding on a loop breaker (which happens for +INLINEABLE), we hang on to the inlining. It's pretty dodgy, but the +user did say 'INLINE'. May need to revisit this choice. Note [Setting the demand info] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -2568,7 +2568,7 @@ An alternative plan is this: but that is bad if 'c' is *not* later scrutinised. So instead we do both: we pass 'c' and 'c#' , and record in c's inlining -(an InlineRule) that it's really I# c#, thus +(a stable unfolding) that it's really I# c#, thus $j = \c# -> \c[=I# c#] -> ...c.... diff --git a/compiler/stranal/WorkWrap.lhs b/compiler/stranal/WorkWrap.lhs index ef2fb53aa6..81bce8c97c 100644 --- a/compiler/stranal/WorkWrap.lhs +++ b/compiler/stranal/WorkWrap.lhs @@ -148,8 +148,8 @@ The only reason this is monadised is for the unique supply. Note [Don't w/w INLINE things] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ It's very important to refrain from w/w-ing an INLINE function (ie one -with an InlineRule) because the wrapper will then overwrite the -InlineRule unfolding. +with a stable unfolding) because the wrapper will then overwrite the +old stable unfolding with the wrapper code. Furthermore, if the programmer has marked something as INLINE, we may lose by w/w'ing it. -- cgit v1.2.1