From e1e1c4133f5627a570feae2e4ba3a9c584462401 Mon Sep 17 00:00:00 2001 From: sof Date: Thu, 4 Sep 1997 20:07:13 +0000 Subject: [PATCH] [project @ 1997-09-04 20:07:13 by sof] doc update --- ghc/compiler/simplCore/OccurAnal.lhs | 24 +++++++++++++++++++++++- 1 file changed, 23 insertions(+), 1 deletion(-) 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 -- 1.7.10.4