On Thu, Aug 04, 2005 at 09:52:18PM +0200, Dominic Dunlop wrote:
> Attached is a comprehensive but simple-minded patch that simply stops
> Perl_peep from recursing to a depth a greater than 8192. When this
> happens, you get a warning, and the code gets run unoptimized.
Perl_peep doesn't just do omptimisations; swome stuff is necessary for
normal running, eg
case OP_METHOD_NAMED:
/* Relocate sv to the pad for thread safety.
> better approach would be to find out why the optimizer thinks it
> needs such a large peephole in this case (more a picture window,
> really) and persuade it to be less ambitious. But I don't understand
> the optimizer at all -- hence the crude solution.
The optimiser processes ops in the order they're normally executed.
For stuff like boolean ops, there's a branch of code which isn't in the
'normal' execution path, eg
if (foo) { bar}
baz;
which is the same as
foo && bar; baz;
the 'normal' path is foo -> baz. So peep recurses down the 'other' branch
to make sure it gets processed too. However, when it follows the bar path,
the next op after bar is baz, so it continues its merry way into the next
statement. Eventually it finisheds returns, and the top-level peep
continues with the next op, baz, but finds it's already been processed,
and so quits.
The fix would probably be to temporary set the 'done' flag on the next op
before recursing. But I havn't got time to look into this yet.
--
I've often wanted to drown my troubles, but I can't get my wife to go
swimming.
