From: simonpj <unknown>
Date: Fri, 4 Jan 2002 11:36:28 +0000 (+0000)
Subject: [project @ 2002-01-04 11:35:47 by simonpj]
X-Git-Tag: Approximately_9120_patches~320
X-Git-Url: http://git.megacz.com/?a=commitdiff_plain;h=13a428caa18deb2805e307cbe7a99fa9f09c13a4;p=ghc-hetmet.git

[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
--- 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
--- 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)