Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!tut.cis.ohio-state.edu!pt.cs.cmu.edu!dsl.pitt.edu!pitt!willett!dwp
From: dwp@willett.pgh.pa.us (Doug Philips)
Newsgroups: comp.lang.forth
Subject: Re: Postfixer FORTH
Message-ID: <1635.UUL1.3#5129@willett.pgh.pa.us>
Date: 29 Aug 90 03:55:41 GMT
References: <1990Aug24.221345.14475@idacom.uucp>
Organization: String, Scotch tape, and Paperclips.  (in Pgh, PA)
Lines: 35

In <1990Aug24.221345.14475@idacom.uucp>, andrew@idacom.uucp (Andrew Scott) writes:
> I hope I understand the issue, as I'm jumping into this discussion thread a
> bit late, but you *did* refer to my article.  :-)

(I was quite surprised when you actually showed up on the net.  Another
lurker out in the open!)

> The question of preventing optimizing across labels is not so academic.  If
> you think of a branch destination like a label, the optimizer queue must be
> "flushed" before the branch is resolved.

Just as I thought.  Thanks for the example.  The code in question was
using multiple entry points, but the issues are the same (I think).
(It matters not where you COME-FROM, but where you are GOING-TO).

I do have a question about your system.  For example:

IF ( code-series-1 ) ELSE ( code-series-2 ) THEN ( code-series-3 )

would it be reasonable, possible, sane, to be able to push copies of
code-series-3 into each branch and see if the optimizer can do better that
way?  If the ELSE was missing you could pretend it was there but empty.  You
can decide when to stop the code motion/duplication based on the length of
the longest of the two optimizer sequences which start with either
code-series-1 or code-series-2.

> I hope this all made some sense...

It did to me, if that is any consolation.

-Doug

---
Preferred: ( dwp@willett.pgh.pa.us  OR  ...!{sei,pitt}!willett!dwp )
Daily: ...!{uunet,nfsun}!willett!dwp  [last resort: dwp@vega.fac.cs.cmu.edu]