> # New Ticket Created by Curtis Rawls > # Please include the string: [perl #36597] > # in the subject line of all future correspondence about this issue. > # <URL: https://rt.perl.org/rt3/Ticket/Display.html?id=36597 >
> This patch adds support for "dominance frontiers" in imcc, including: > -Array of Sets for dominance frontiers > -An efficient algorithm described in "A Simple, Fast Dominance > Algorithm", Cooper et al. (2001) > -Free and dump functions
> # New Ticket Created by Curtis Rawls > # Please include the string: [perl #36597] > # in the subject line of all future correspondence about this issue. > # <URL: https://rt.perl.org/rt3/Ticket/Display.html?id=36597 >
> This patch adds support for "dominance frontiers" in imcc, including: > -Array of Sets for dominance frontiers > -An efficient algorithm described in "A Simple, Fast Dominance > Algorithm", Cooper et al. (2001) > -Free and dump functions
The eval tests are failing with a pristine checkout so we can ignore those. Applying your patch to a pristine build yields only the backtrack.t failure: #2 eats 100% of the CPU until I kill it: it doesn't behave that way in svn-head.
Looks like PerlString and String were red herrings. Should track down why p6rules is misbehaving with your patch, though.
> Failed Test Stat Wstat Total Fail Failed List of Failed > ---------------------------------------------------------------------- > --------- > t/p6rules/backtrack.t 1 256 15 1 6.67% 2 > t/pmc/eval.t 3 768 14 3 21.43% 12-14 > t/pmc/perlstring.t 1 256 68 1 1.47% 61 > t/pmc/string.t 1 256 35 1 2.86% 28
> I have some slight differences from svn-latest which of course > "shouldn't affect these tests". =-)
> On Jul 19, 2005, at 10:39 PM, Curtis Rawls (via RT) wrote:
>> # New Ticket Created by Curtis Rawls >> # Please include the string: [perl #36597] >> # in the subject line of all future correspondence about this issue. >> # <URL: https://rt.perl.org/rt3/Ticket/Display.html?id=36597 >
>> This patch adds support for "dominance frontiers" in imcc, including: >> -Array of Sets for dominance frontiers >> -An efficient algorithm described in "A Simple, Fast Dominance >> Algorithm", Cooper et al. (2001) >> -Free and dump functions
On Thu, 28 Jul 2005, Will Coleda wrote: > Applying your patch to a pristine build yields only the backtrack.t failure: > #2 eats 100% of the CPU until I kill it: it doesn't behave that way in > svn-head.
I can confirm the backtrack #2 failure under SPARC/Solaris. I can't say what other tests may have changed; the script I had running the comparison got stuck at backtrack.t and never finished.
Thanks for pointing this out. I tracked the bug down, and it looks like the dominator algorithm does not handle unreachable blocks correctly, and the dominance frontier algorithm suffers for it. Why the unreachable blocks are generated in the first place might be an interesting question for someone working on PGE.
I'll work on the dominator bug before applying the DF patch. -Curtis
> The eval tests are failing with a pristine checkout so we can ignore > those. Applying your patch to a pristine build yields only the > backtrack.t failure: #2 eats 100% of the CPU until I kill it: it > doesn't behave that way in svn-head.
> Looks like PerlString and String were red herrings. Should track down > why p6rules is misbehaving with your patch, though.
> > I have some slight differences from svn-latest which of course > > "shouldn't affect these tests". =-)
> > On Jul 19, 2005, at 10:39 PM, Curtis Rawls (via RT) wrote:
> >> # New Ticket Created by Curtis Rawls > >> # Please include the string: [perl #36597] > >> # in the subject line of all future correspondence about this issue. > >> # <URL: https://rt.perl.org/rt3/Ticket/Display.html?id=36597 >
> >> This patch adds support for "dominance frontiers" in imcc, including: > >> -Array of Sets for dominance frontiers > >> -An efficient algorithm described in "A Simple, Fast Dominance > >> Algorithm", Cooper et al. (2001) > >> -Free and dump functions
On Thu, Jul 28, 2005 at 03:39:33PM -0400, Andy Dougherty wrote: > On Thu, 28 Jul 2005, Will Coleda wrote:
> > Applying your patch to a pristine build yields only the backtrack.t failure: > > #2 eats 100% of the CPU until I kill it: it doesn't behave that way in > > svn-head.
> I can confirm the backtrack #2 failure under SPARC/Solaris. I can't say > what other tests may have changed; the script I had running the comparison > got stuck at backtrack.t and never finished.
Just to add to the picture -- I also tried applying df.patch to a fresh checkout of parrot/trunk (r8727), and also observed the same problem of getting stuck on test #2 in t/p6rules/backtrack.t . (FWIW, I'm running Fedora Core 4.)
Some additional investigation reveals that with df.patch applied it's the PIR compiler that is getting stuck. I'm able to reproduce this with the code below, which doesn't do anything useful other than demonstrate that the compiler gets stuck when one tries to compile:
$ cat x4.pir .sub foo print "started\n" bsr R1 goto end R1: goto R2 if $I0 goto R2 bsr R2 R2: ret end: .end
at which point the process is stuck until interrupted somehow.
The problem seems to be with the exact goto/if/bsr sequence given in R1 -- remove any of them or reorder them and the code successfully compiles.
I completely grant that the specific sequence of statements that trigger this problem is bizarre -- it only occurred in PGE because of a missing optimization in PGE's code generator. The cut operator (for backtracking control) generated a "goto R2" statement to handle the cut, but then also generated the code that would've performed the backtracking had the cut not been present. Note that having the extra code after the goto doesn't change the syntactic or semantic correctness at all -- it just causes the compiler to choke somehow (when df.patch is applied).
I'll definitely fix PGE to not generate the unnecessary code following the "goto", but it seems to me that the compiler should not hang on something like this in any case.
I'll be very happy to add the above PIR segment to the imcc test suite if someone can tell me which imcc/t/*/*.t file it should go in. Then I'll fix PGE to not generate the code it should not have been generating in the first place. :-)
> > On 7/28/05, Leopold Toetsch <l...@toetsch.at> wrote:
> >> On Jul 28, 2005, at 18:53, Curtis Rawls wrote:
> >>> Can someone apply this? I have another patch ready that depends on > >>> this one. > >>> Thanks!
> >> Please send me you auth.perl account name, I'll forward it with > >> approval to Robert, so that you get ci privs for parrot (if ypu want > >> of > >> course :-)
> Thanks for pointing this out. I tracked the bug down, and it looks > like the dominator algorithm does not handle unreachable blocks > correctly, and the dominance frontier algorithm suffers for it. Why > the unreachable blocks are generated in the first place might be an > interesting question for someone working on PGE.
> I'll work on the dominator bug before applying the DF patch. > -Curtis
> On 7/28/05, Will Coleda <w...@coleda.com> wrote: > > The eval tests are failing with a pristine checkout so we can ignore > > those. Applying your patch to a pristine build yields only the > > backtrack.t failure: #2 eats 100% of the CPU until I kill it: it > > doesn't behave that way in svn-head.
> > Looks like PerlString and String were red herrings. Should track down > > why p6rules is misbehaving with your patch, though.
> > Regards.
> > On Jul 28, 2005, at 1:55 PM, Will Coleda wrote:
> > > I have some slight differences from svn-latest which of course > > > "shouldn't affect these tests". =-)
> > > On Jul 19, 2005, at 10:39 PM, Curtis Rawls (via RT) wrote:
> > >> # New Ticket Created by Curtis Rawls > > >> # Please include the string: [perl #36597] > > >> # in the subject line of all future correspondence about this issue. > > >> # <URL: https://rt.perl.org/rt3/Ticket/Display.html?id=36597 >
> > >> This patch adds support for "dominance frontiers" in imcc, including: > > >> -Array of Sets for dominance frontiers > > >> -An efficient algorithm described in "A Simple, Fast Dominance > > >> Algorithm", Cooper et al. (2001) > > >> -Free and dump functions
|
