diff options
Diffstat (limited to 'compiler')
| -rw-r--r-- | compiler/coreSyn/CoreSyn.hs | 2 | ||||
| -rw-r--r-- | compiler/coreSyn/CoreUnfold.hs | 8 | ||||
| -rw-r--r-- | compiler/simplCore/OccurAnal.hs | 10 | ||||
| -rw-r--r-- | compiler/simplCore/Simplify.hs | 2 | ||||
| -rw-r--r-- | compiler/specialise/SpecConstr.hs | 2 | ||||
| -rw-r--r-- | compiler/specialise/Specialise.hs | 14 |
6 files changed, 19 insertions, 19 deletions
diff --git a/compiler/coreSyn/CoreSyn.hs b/compiler/coreSyn/CoreSyn.hs index c1ae518927..6a70f2c8ab 100644 --- a/compiler/coreSyn/CoreSyn.hs +++ b/compiler/coreSyn/CoreSyn.hs @@ -1243,7 +1243,7 @@ expandUnfolding_maybe _ = hasStableCoreUnfolding_maybe :: Unfolding -> Maybe Bool -- Just True <=> has stable inlining, very keen to inline (eg. INLINE pragma) --- Just False <=> has stable inlining, open to inlining it (eg. INLINEABLE pragma) +-- Just False <=> has stable inlining, open to inlining it (eg. INLINABLE pragma) -- Nothing <=> not stable, or cannot inline it anyway hasStableCoreUnfolding_maybe (CoreUnfolding { uf_src = src, uf_guidance = guide }) | isStableSource src diff --git a/compiler/coreSyn/CoreUnfold.hs b/compiler/coreSyn/CoreUnfold.hs index c613ceb20c..7faee6349e 100644 --- a/compiler/coreSyn/CoreUnfold.hs +++ b/compiler/coreSyn/CoreUnfold.hs @@ -199,22 +199,22 @@ specUnfolding to specialise its unfolding. Some important points: * There is a bit of hack for INLINABLE functions: f :: Ord a => .... f = <big-rhs> - {- INLINEABLE f #-} + {- INLINABLE f #-} Now if we specialise f, should the specialised version still have - an INLINEABLE pragma? If it does, we'll capture a specialised copy + an INLINABLE pragma? If it does, we'll capture a specialised copy of <big-rhs> as its unfolding, and that probaby won't inline. But if we don't, the specialised version of <big-rhs> might be small enough to inline at a call site. This happens with Control.Monad.liftM3, and can cause a lot more allocation as a result (nofib n-body shows this). - Moreover, keeping the INLINEABLE thing isn't much help, because + Moreover, keeping the INLINABLE thing isn't much help, because the specialised function (probaby) isn't overloaded any more. Conclusion: drop the INLINEALE pragma. In practice what this means is: if a stable unfolding has UnfoldingGuidance of UnfWhen, we keep it (so the specialised thing too will always inline) if a stable unfolding has UnfoldingGuidance of UnfIfGoodArgs - (which arises from INLINEABLE), we discard it + (which arises from INLINABLE), we discard it -} mkCoreUnfolding :: UnfoldingSource -> Bool -> CoreExpr diff --git a/compiler/simplCore/OccurAnal.hs b/compiler/simplCore/OccurAnal.hs index 27e5a7d97e..1186d0d28c 100644 --- a/compiler/simplCore/OccurAnal.hs +++ b/compiler/simplCore/OccurAnal.hs @@ -927,7 +927,7 @@ reOrderNodes depth bndr_set weak_fvs (node : nodes) binds -- Note [DFuns should not be loop breakers] | Just be_very_keen <- hasStableCoreUnfolding_maybe (idUnfolding bndr) - = if be_very_keen then 6 -- Note [Loop breakers and INLINE/INLINEABLE pragmas] + = if be_very_keen then 6 -- Note [Loop breakers and INLINE/INLINABLE pragmas] else 3 -- Data structures are more important than INLINE pragmas -- so that dictionary/method recursion unravels @@ -1010,18 +1010,18 @@ The RULES stuff means that we can't choose $dm as a loop breaker opInt *and* opBool, and so on. The number of loop breakders is linear in the number of instance declarations. -Note [Loop breakers and INLINE/INLINEABLE pragmas] +Note [Loop breakers and INLINE/INLINABLE pragmas] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Avoid choosing a function with an INLINE pramga as the loop breaker! If such a function is mutually-recursive with a non-INLINE thing, then the latter should be the loop-breaker. -It's vital to distinguish between INLINE and INLINEABLE (the +It's vital to distinguish between INLINE and INLINABLE (the Bool returned by hasStableCoreUnfolding_maybe). If we start with - Rec { {-# INLINEABLE f #-} + Rec { {-# INLINABLE f #-} f x = ...f... } and then worker/wrapper it through strictness analysis, we'll get - Rec { {-# INLINEABLE $wf #-} + Rec { {-# INLINABLE $wf #-} $wf p q = let x = (p,q) in ...f... {-# INLINE f #-} diff --git a/compiler/simplCore/Simplify.hs b/compiler/simplCore/Simplify.hs index 47c9323ce1..d52aacdde5 100644 --- a/compiler/simplCore/Simplify.hs +++ b/compiler/simplCore/Simplify.hs @@ -2969,7 +2969,7 @@ Note [Setting the new unfolding] can get into an infinite loop 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 +INLINABLE), we hang on to the inlining. It's pretty dodgy, but the user did say 'INLINE'. May need to revisit this choice. ************************************************************************ diff --git a/compiler/specialise/SpecConstr.hs b/compiler/specialise/SpecConstr.hs index b485f750e4..60632255d8 100644 --- a/compiler/specialise/SpecConstr.hs +++ b/compiler/specialise/SpecConstr.hs @@ -421,7 +421,7 @@ This seeding is done in the binding for seed_calls in specRec. Actually in case (2), instead of using the calls from the RHS, it would be better to specialise in the importing module. We'd need to -add an INLINEABLE pragma to the function, and then it can be +add an INLINABLE pragma to the function, and then it can be specialised in the importing scope, just as is done for type classes in Specialise.specImports. This remains to be done (#10346). diff --git a/compiler/specialise/Specialise.hs b/compiler/specialise/Specialise.hs index e90ea129cd..e562e606ee 100644 --- a/compiler/specialise/Specialise.hs +++ b/compiler/specialise/Specialise.hs @@ -624,7 +624,7 @@ for instance, the 'specImports' call in 'specProgram'. Note [Disabling cross-module specialisation] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -Since GHC 7.10 we have performed specialisation of INLINEABLE bindings living +Since GHC 7.10 we have performed specialisation of INLINABLE bindings living in modules outside of the current module. This can sometimes uncover user code which explodes in size when aggressively optimized. The -fno-cross-module-specialise option was introduced to allow users to being @@ -725,7 +725,7 @@ specImport dflags this_mod top_env done callers rb fn calls_for_fn 2 (vcat [ text "when specialising" <+> quotes (ppr caller) | caller <- callers]) , ifPprDebug (text "calls:" <+> vcat (map (pprCallInfo fn) calls_for_fn)) - , text "Probable fix: add INLINEABLE pragma on" <+> quotes (ppr fn) ]) + , text "Probable fix: add INLINABLE pragma on" <+> quotes (ppr fn) ]) ; return ([], []) } | otherwise @@ -757,17 +757,17 @@ wantSpecImport dflags unf -- 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] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Suppose - * In module Lib, you carefully mark a function 'foo' INLINEABLE + * In module Lib, you carefully mark a function 'foo' INLINABLE * Import Lib(foo) into another module M * Call 'foo' at some specialised type in M Then you jolly well expect it to be specialised in M. But what if 'foo' calls another function 'Lib.bar'. Then you'd like 'bar' to be -specialised too. But if 'bar' is not marked INLINEABLE it may well +specialised too. But if 'bar' is not marked INLINABLE it may well not be specialised. The warning Opt_WarnMissedSpecs warns about this. It's more noisy to warning about a missed specialisation opportunity @@ -1362,7 +1362,7 @@ complicated Refl coercions with Refl pretty aggressively. Note [Orphans and auto-generated rules] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -When we specialise an INLINEABLE function, or when we have +When we specialise an INLINABLE function, or when we have -fspecialise-aggressively, we auto-generate RULES that are orphans. We don't want to warn about these, or we'd generate a lot of warnings. Thus, we only warn about user-specified orphan rules. @@ -1687,7 +1687,7 @@ all they should be inlined, right? Two reasons: This particular example had a huge effect on the call to replicateM_ in nofib/shootout/n-body. -Why (b): discard INLINEABLE pragmas? See Trac #4874 for persuasive examples. +Why (b): discard INLINABLE pragmas? See Trac #4874 for persuasive examples. Suppose we have {-# INLINABLE f #-} f :: Ord a => [a] -> Int |