[project @ 2002-01-04 11:35:47 by simonpj]

Comments only

diff --git a/ghc/compiler/coreSyn/CoreUnfold.lhs b/ghc/compiler/coreSyn/CoreUnfold.lhs
index 457f9cf..9046341 100644 (file)
--- a/ghc/compiler/coreSyn/CoreUnfold.lhs
+++ b/ghc/compiler/coreSyn/CoreUnfold.lhs
@@ -578,6 +578,11 @@ callSiteInline dflags active_inline inline_call occ id arg_infos interesting_con
                -- then if the context is totally uninteresting (not applied, not scrutinised)
                -- there is no point in substituting because it might just increase allocation,
                -- by allocating the function itself many times
+               -- Note [Jan 2002]: this comment looks out of date.  The actual code
+               -- doesn't inline *ever* in an uninteresting context.  Why not?  I
+               -- think it's just because we don't want to inline top-level constants
+               -- into uninteresting contexts, lest we (for example) re-nest top-level
+               -- literal lists.
                --
                -- Note: there used to be a '&& not top_level' in the guard above,
                --       but that stopped us inlining top-level functions used only once,

diff --git a/ghc/compiler/simplCore/SimplMonad.lhs b/ghc/compiler/simplCore/SimplMonad.lhs
index 27c9eec..800334c 100644 (file)
--- a/ghc/compiler/simplCore/SimplMonad.lhs
+++ b/ghc/compiler/simplCore/SimplMonad.lhs
@@ -756,7 +756,16 @@ big the RHS might be.  If this is the case we don't simplify the RHS
 first, but just inline it un-simplified.
 
 This is much better than first simplifying a perhaps-huge RHS and then
-inlining and re-simplifying it.
+inlining and re-simplifying it.  Indeed, it can be at least quadratically
+better.  Consider
+
+       x1 = e1
+       x2 = e2[x1]
+       x3 = e3[x2]
+       ...etc...
+       xN = eN[xN-1]
+
+We may end up simplifying e1 N times, e2 N-1 times, e3 N-3 times etc.
 
 NB: we don't even look at the RHS to see if it's trivial
 We might have
@@ -785,6 +794,9 @@ seems to be to do a callSiteInline based on the fact that there is
 something interesting about the call site (it's strict).  Hmm.  That
 seems a bit fragile.
 
+Conclusion: inline top level things gaily until Phase 0 (the last
+phase), at which point don't.
+
 \begin{code}
 preInlineUnconditionally :: SimplEnv -> TopLevelFlag -> InId -> Bool
 preInlineUnconditionally env top_lvl bndr
@@ -795,7 +807,7 @@ preInlineUnconditionally env top_lvl bndr
 -- top level, and preInlineUnconditionally floats them all back in.
 -- Result is (a) static allocation replaced by dynamic allocation
 --          (b) many simplifier iterations because this tickles
---              a related problem
+--              a related problem; only one inlining per pass
 -- 
 -- On the other hand, I have seen cases where top-level fusion is
 -- lost if we don't inline top level thing (e.g. string constants)