[perl #33032] Parameter fillin problem
Dan Sugalski
# Please include the string: [perl #33032]
# in the subject line of all future correspondence about this issue.
# <URL: http://rt.perl.org:80/rt3/Ticket/Display.html?id=33032 >
IMCC's doing odd things when moving PMCs into the appropriate spot
when calling into functions with a large number of parameters. Here's
a snip from a trace of one of the programs running. Note the lines
from bytecode offset 78123, 78126, and 78130. P9 is set to P28 (which
is right) then P9 is set to spill 64, which is then moved to register
P10 (leaving the same PMC in P9 and P10, which isn't correct)
The IMCC code that corresponds to the executed bytecode is:
$P1867 = $P1868('metadata/priceq_extra.info', $P1803, $P1806, $P1809,
$P1812, $P1815, $P1818, $P1821, $P1824, $P1827, $P1830, $P1833,
$P1836, $P1839, $P1842, $P1845, $P1848, $P1851, $P1854, $P1857,
$P1860, $P1863, $P1866)
78111 set P5, P17 - P5=Array=PMC(0x22e6110),
P17=Object(DPString)=PMC(0x22d1590)
78114 set P6, P16 - P6=Object(DPString)=PMC(0x22e8810),
P16=Object(DPString)=PMC(0x22d12c0)
78117 set P7, P30 - P7=Object(DPString)=PMC(0x22e8588),
P30=Object(Int32)=PMC(0x22d10b0)
78120 set P8, P29 - P8=Object(DPString)=PMC(0x22e82b8),
P29=Object(Money4)=PMC(0x22d0f00)
78123 set P9, P28 - P9=Object(DPString)=PMC(0x22e7fe8),
P28=Object(Int32)=PMC(0x22d0d50)
78126 set P9, P31[64] - P9=Object(Int32)=PMC(0x22d0d50),
P31=PerlArray=PMC(0x101b6d8),
78130 set P10, P9 - P10=Object(DPString)=PMC(0x22e7d18),
P9=Object(Money4)=PMC(0x22d0ba0)
78133 set P10, P31[63] - P10=Object(Money4)=PMC(0x22d0ba0),
P31=PerlArray=PMC(0x101b6d8),
78137 set P11, P10 - P11=Object(DPString)=PMC(0x22e7a48),
P10=Object(Int32)=PMC(0x22d09f0)
78140 set P11, P31[62] - P11=Object(Int32)=PMC(0x22d09f0),
P31=PerlArray=PMC(0x101b6d8),
78144 set P12, P11 - P12=Object(DPString)=PMC(0x22e7778),
P11=Object(Money4)=PMC(0x22d0858)
78147 set P12, P31[61] - P12=Object(Money4)=PMC(0x22d0858),
P31=PerlArray=PMC(0x101b6d8),
78151 set P13, P12 - P13=Object(DPString)=PMC(0x22e74a8),
P12=Object(Int32)=PMC(0x22d06a8)
78154 set P13, P31[60] - P13=Object(Int32)=PMC(0x22d06a8),
P31=PerlArray=PMC(0x101b6d8),
78158 set P14, P13 - P14=Object(DPString)=PMC(0x22e71d8),
P13=Object(Money4)=PMC(0x22d04f8)
78161 null P3 - P3=Sub=PMC(0xff3868 Adr:0x2113144)
78163 set P14, P31[59] - P14=Object(Money4)=PMC(0x22d04f8),
P31=PerlArray=PMC(0x101b6d8),
78167 set P15, P14 - P15=Object(DPString)=PMC(0x22e6f08),
P14=Object(Int32)=PMC(0x22d0348)
--
Dan
--------------------------------------it's like this-------------------
Dan Sugalski even samurai
d...@sidhe.org have teddy bears and even
teddy bears get drunk
Leopold Toetsch
> IMCC's doing odd things when moving PMCs into the appropriate spot
> when calling into functions with a large number of parameters. Here's
> a snip from a trace of one of the programs running. Note the lines
> from bytecode offset 78123, 78126, and 78130. P9 is set to P28 (which
> is right) then P9 is set to spill 64, which is then moved to register
> P10 (leaving the same PMC in P9 and P10, which isn't correct)
I tried to reproduce it but failed. I've added more tests that all spill
correctly.
Are you using CVS head?
leo
Dan Sugalski
Damn. No, I'm using a build from Nov 30th. Syncing up with CVS head
breaks this code in other interesting ways. I'll go close this bug
and track down the current problems.
Dan Sugalski
>At 9:08 AM +0000 12/14/04, Leopold Toetsch via RT wrote:
>>Dan Sugalski <parrotbug...@parrotcode.org> wrote:
>>
>>> IMCC's doing odd things when moving PMCs into the appropriate spot
>>> when calling into functions with a large number of parameters. Here's
>>> a snip from a trace of one of the programs running. Note the lines
>>> from bytecode offset 78123, 78126, and 78130. P9 is set to P28 (which
>>> is right) then P9 is set to spill 64, which is then moved to register
>>> P10 (leaving the same PMC in P9 and P10, which isn't correct)
>>
>>I tried to reproduce it but failed. I've added more tests that all spill
>>correctly.
>>
>>Are you using CVS head?
>
>Damn. No, I'm using a build from Nov 30th. Syncing up with CVS head
>breaks this code in other interesting ways. I'll go close this bug
>and track down the current problems.
Or not. (I've got too many versions of parrot around at the moment) I
see this bug happening against yesterday morning's parrot.
imcc/CVS/Entries shows a date of Mon Dec 13 12:19:33 2004 for
reg_alloc.c.
Leopold Toetsch
>
> Or not. (I've got too many versions of parrot around at the moment) I
> see this bug happening against yesterday morning's parrot.
> imcc/CVS/Entries shows a date of Mon Dec 13 12:19:33 2004 for reg_alloc.c.
I still can't reproduce it. CVS fetches either to P16 or even P3 for the
first registers until P3 is used to hold overflow.
leo
Dan Sugalski
From what I can see it's inconsistent--I've only tracked down one
function call where this happens, though I've not dug in too deeply
yet. (I was hoping there was something in the code that'd trigger a
"D'oh!" and easy fix :)
I'll do a compile-to-pasm and grovel through the code some more to
see if I can't find some marker or other that might show what's going
on.