On 5/28/07, Donal K. Fellows <donal.k.fellows@[...].uk>  wrote:

> 
>  Initially, you only get to determine what "leaf" procedures are up to,
>  but with the leaves figured out, you'll be able to go further up the
>  call tree and optimize things further (a procedure is non-tricky if it
>  does not call anything tricky).


Yes, that sounds like a reasonable first step towards aggressive bytecode
optimizations.

Now, in cases unreachable by this transitive closure strategy, we may still
have a card to play.
When we "optimize away" variable as a stack position, we also leave a hint
of this operation (at compile time) in the scope's var-hashtable (it could
be implemented as a read and write trace, but purely at C level)
Whenever unknowing code from a callee upvar's this variable, the rw trace
steps in and maps to the proper location.
The idea, as you suggest, is that most of the code will not be hampered by
this mechanism (no trace, and no perf hit except at compile time), and the
rest will "deserve" it (in the sense that access-by-name is a noble task
that justifies a higher cost). Moreover, most obvious cases of upvar access
(incr, lappend) can be inlined to do the obvious thing, directly on the
stack.
I know this is very preliminary, feel free to destroy this dream...

-Alex