# New Ticket Created by Allison Randal # Please include the string: [perl #57028] # in the subject line of all future correspondence about this issue. # <URL: http://rt.perl.org/rt3/Ticket/Display.html?id=57028 >
In a joint deugging session, chromatic and I confirmed that this is indeed a bug in the register allocator, specifically in the graph coloring register allocator, and not in the vanilla allocator (which is why it works when run outside the test harness, because Parrot is defaulting to the vanilla allocator). There's code in the allocator that turns off certain optimizations when it encounters the branching ops, and we need to treat 'local_branch' and 'local_return' similarly. For now, we've turned off the graph coloring allocator, so the pdd25cx branch passes all its tests, and language testing on the branch can proceed. This ticket is to remind us to look back into the graph coloring allocator. Also marked the following tests as TODO, because they expect the graph coloring allocator to be selected during the test run. t/compilers/imcc/imcpasm/optc.t #9 t/compilers/imcc/imcpasm/opt0.t #1 and 3 Allison Patrick R. Michaud wrote: > The attached trace.out file contains a trace that demonstrates > why PGE is failing its tests in the pdd25cx branch. I suspect > the problem is with the register allocator -- perhaps being > unable to correctly map registers when local_branch and > local_return instructions are present. > > The line where the problem first manifests is PGE/OPTable.pir:331 : > > if has_stop == 0 goto key_search > > This line occurs in a loop that starts at the 'token_next' label > on 309. Inside of that loop, the value of has_stop is never > modified (in fact, it's not modified at all after the 'with_stop' > label on line 280). > > The first time the if statement above is executed, has_stop > correctly has a value of 1, as shown by line 97 in the > trace output: > > # 1303 eq I5, 0, 40 I5=1 > > The next time through the loop, however, the value of has_stop > (I5) has somehow been changed to zero (line 742 in the trace > output), even though the original PIR doesn't modify has_stop > at any point in the loop. > > # 1303 eq I5, 0, 40 I5=0 > > Line 128 of the trace seems to show where the I5 register is > first modified after having had the correct value at line 97: > > # 1856 set I5, P7["wb"] I5=1 P7=Hash=PMC(0x8454a98) > > This corresponds to line 539 of PGE/OPTable.pir: > > $I1 = token['wb'] > > The trace also shows the I5 register being modified at line > 654 of the trace, which corresponds to line 492 of PGE/OPTable.pir: > > # 1710 set I5, P9["arity"] I5=0 P9=Hash=PMC(0x8455454) > > arity = top['arity'] > > So, somehow imcc is re-using the same I5 register for each > of has_stop, arity, and $I1 registers in the 'parse' method. > > At the bottom of this message are the instructions for reproducing > this trace, as well as some other oddities I've noticed. > > I did try adding :unique_reg to all of the named registers > in the 'parse' method where this problem occurs, but immc > still ended up reusing the C<has_stop> register for use in > the C<$I1 = token['wb']> instruction on PGE/OPTable.pir line 539. > > So, for a complete workaround I suppose we could try eliminating > all "temporary" registers from the parse method as well, so > that only named registers are used and they are always > flagged with :unique_reg. But, before I do that I wanted > to see if there were other options to explore first. (If we > take the :unique_reg approach, we will probably have to > do the same for generated code coming from PGE/Exp.pir and > other places that make use of local_branch/local_return.) > > Hope this helps, > > Pm > > ----steps to produce the trace output on my system---- > > * Place the attached "03-optable.t" file in the parrot > root directory. This file is a version of > t/compilers/pge/03-optable.t that has been modified > to only run one failing test and to enable tracing > of the 'parse' method invocation. > > * Run "prove 03-optable.t >trace.out 2>&1" to produce > a trace.out file. > > Two very interesting observations: > > 1. On my system, the test is sensitive to the name of > the test file. For example, if I rename '03-optable.t' > to 'opbug.t' and run prove on it as above then I get > a different trace and the bug no longer manifests. > > 2. Running parrot directly on the 03-optable_1.pir > file that is generated by the 'prove' step above > produces the correct output, and the output > trace indicates that different registers are being > used as compared to when the program was run using 'prove' > (even though the same 03-optable_1.pir file is used > in both instances). >
