[perl #38264] Bug in compute_dominance_frontiers?

The attached code compiles to byte code OK in r11235, until you
comment out the push_eh indicated by the patch, which makes
compute_dominance_frontiers take forever. (Sorry; I wish I had time to
try to make it smaller.) TIA,

-- Bob Rogers
http://rgrjr.dyndns.org/

In the meantime, we don't actually need compute_dominance_frontiers unless
we are optimizing so far as I can see, so I have ci'd a change to only do
that when the optimize flag is set.

I've cc'd in Curtis Rawls who I believe implemented the routine - Curtis,
any chance you may have time to have a quick look at this?

Thanks,

Jonathan

On 14-Jan-06 I had done some hacking on my compiler using r11187, and
all worked fine when I did my last checkin that day. When I updated to
r11220 late on 16-Jan-06, doing the standard "make clean test" on my
code broke mysteriously in a number of places. I found two separate
syndromes by the time I had to quit:

1. Several of the cases were segfaulting; the only one I looked at
in detail was doing mark_context from Parrot_Closure_mark.

2. One case reported ":outer '_test_1' not found" where _test_1
existed but declared no lexicals (i.e. the "closure" had no variables
closed over); deleting the :outer construct from the inner sub made it
work. I was tracking this down when I stumbled onto the
compute_dominance_frontiers issue, which I assumed was yet another bug.

But maybe not. This evening, after updating to Parrot r11257, doing
"make clean test" on my code worked just fine. That suggests that
compute_dominance_frontiers became subtly broken between r11187 and
r11220, but too subtly for the test suite to detect it (which is kinda
scary).

FWIW, if I try 'parrot -O1' or 'parrot -O2' in r11257, it doesn't
even compile my code; it segfaults in branch_reorg in some place
completely different. Caveat optimizator, I guess . . .

-- Bob

P.S. I needed to resend this in order to get it into RT.

In fact, the dominance frontier information is only useful for SSA,
which is not completed, so you would be just as well off commenting
out the entire compute_dominance_frontiers call in reg_alloc.c until
it is needed.

I don't see that any changes have been made to the algorithm itself,
so I guess the dominator tree input has been altered in some way that
was assumed to be stable. If there was a smaller failing test case I
could try to debug it and see what's going on.
-Curtis

>
> Thanks,
>
> Jonathan

P.S. All of the updates were obvious (change "PerlInt" to "Integer",
etc.), so I see no point in attaching the updated PIR code.