On Wed, Nov 07, 2001 at 05:15:14PM -0500, Dan Sugalski wrote:
*) The program is fully parsed
*) There are no string eval, do, or requires
*) There are no symbolic references on the LHS of any assignment
*) There is no use of MY within the block or in any subs called by
> Since you don't know, you can't assume it'll do something safe. And while
> it's potentially possible you just de-optimize code, it's fairly
> non-trivial to recompile a block you're already in the middle of,
> especially if you're in the middle of another block (like a sub) and need
> to rebuild a parent block such that you can still return to the spot you
> left from. (Try it when the code that triggers the recompile is caused by
> accessing a tied variable so that you're rebuilding an expression you might
> be in the middle of)
Is there enough win in doing that optimisation on an innermost block that
doesn't call anything?
Maybe on a deferred basis - track if the block is suitable for optimising on
the first run through, and if it loops at the end then do the serious
optimisation.
That way, something like
while (<>) {
print if /foo/;
}
would run through for the first line and if it found no violations of your 4
bullet points by the end of the block, it would then perform the vtable bypass
operation on that block only.
Also, after reading this thread, I suspect that interpreter generated
things like the (lazy?) list due to .. in
foreach (1..10000) {
}
will find fast integer ops useful.
Nicholas Clark
