From: sof <unknown>
Date: Thu, 4 Sep 1997 20:07:13 +0000 (+0000)
Subject: [project @ 1997-09-04 20:07:13 by sof]
X-Git-Tag: Approximately_1000_patches_recorded~17
X-Git-Url: http://git.megacz.com/?p=ghc-hetmet.git;a=commitdiff_plain;h=e1e1c4133f5627a570feae2e4ba3a9c584462401

[project @ 1997-09-04 20:07:13 by sof]
doc update
---

diff --git a/ghc/compiler/simplCore/OccurAnal.lhs b/ghc/compiler/simplCore/OccurAnal.lhs
index 8bde1c9..622430d 100644
--- a/ghc/compiler/simplCore/OccurAnal.lhs
+++ b/ghc/compiler/simplCore/OccurAnal.lhs
@@ -425,10 +425,32 @@ Here's a case that bit me:
 	...a...a...a....
 
 Re-ordering doesn't change the order of bindings, but there was no loop-breaker.
-(The first binding was a var-rhs; the second was a one-occ.)  So the simplifier looped.
+
 My solution was to make a=b bindings record b as Many, rather like INLINE bindings.
 Perhaps something cleverer would suffice.
 
+You might think that you can prevent non-termination simply by making
+sure that we simplify a recursive binding's RHS in an environment that
+simply clones the recursive Id.  But no.  Consider
+
+		letrec f = \x -> let z = f x' in ...
+
+		in
+		let n = f y
+		in
+		case n of { ... }
+
+We bind n to its *simplified* RHS, we then *re-simplify* it when
+we inline n.  Then we may well inline f; and then the same thing
+happens with z!
+
+I don't think it's possible to prevent non-termination by environment
+manipulation in this way.  Apart from anything else, successive
+iterations of the simplifier may unroll recursive loops in cases like
+that above.  The idea of beaking every recursive loop with an
+IMustNotBeINLINEd pragma is much much better.
+
+
 \begin{code}
 reOrderRec
 	:: OccEnv