imcc code generation problem
Nick Glencross
I'll log a bug for this if need be, but I'd rather solve the problem myself
(with some help). I'm in the middle of writing a routine (MD5 hashing for
fun), and stumbled upon the following code generation problem in imcc.
In the attached code, I've got
$I10 = word & 0x000000ff
$I11 = word & 0x0000ff00
$I12 = word & 0x00ff0000
$I13 = word & 0xff000000
and the resulting code becomes
band I17, I16, 0x000000ff
band I17, I16, 0x0000ff00
band I17, I16, 0x00ff0000
band I16, I16, 0xff000000
Although $I10 to $I13 are all temps that are never used, I16 seems to become
corrupted.
Can anyone shed some light on the area that I should be looking at; I
guessing that it's to do with the code paths confusing things, or simply
that the values are never used. Actually using $I13 seems to fix the problem
(e.g. print $I13).
Some hints (such as deciphering parrot -d 8) would be appreciated,
Regards,
Nick Glencross
Dan Sugalski
>Ok, so doing a 'parrot -d 8' shows that word doesn't seem to
>interfere with $I13 as far as it is concerned ...
>
>
>Dumping the Interf. graph:
>-------------------------------
>...
>word -> $I10 $I11 $I12 (3)
>...
>$I10 -> word (1)
>$I11 -> word (1)
>$I12 -> word (1)
>$I13 -> (0)
>...
>
>I wonder if it's because the lifetime of $I13 stops and starts on
>the same line that word stops?
I'd bet that's it--the lifetime tracing code may be getting a bit
aggressive, and the label throws in another basic block (sorta) which
helps perturb things. (This is all pretty hand-wavey, though)
If you're feeling adventurous, that'd be a good spot to dive into the
imcc source to go look for the problem.
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
d...@sidhe.org have teddy bears and even
teddy bears get drunk
Nick Glencross
$I13 as far as it is concerned ...
Dumping the Interf. graph:
-------------------------------
...
word -> $I10 $I11 $I12 (3)
...
$I10 -> word (1)
$I11 -> word (1)
$I12 -> word (1)
$I13 -> (0)
...
I wonder if it's because the lifetime of $I13 stops and starts on the same
line that word stops?
One thing that I forgot to add before was that simply removing the label in
the code makes things work, and you get a totally different debug trace.
I must stop talking to myself like this. I probably won't post again until
I've made /alot/ more progress,
Nick
Leopold Toetsch
> $I10 = word & 0x000000ff
> $I11 = word & 0x0000ff00
> $I12 = word & 0x00ff0000
> $I13 = word & 0xff000000
> and the resulting code becomes
> band I17, I16, 0x000000ff
> band I17, I16, 0x0000ff00
> band I17, I16, 0x00ff0000
> band I16, I16, 0xff000000
> Although $I10 to $I13 are all temps that are never used
Well. That's it. Just use $I10 ... $I13 and they will stay what they
were. Put a print thereafter for debugging which uses these regs.
The life analysis doesn't see any more usage of these registers. So they
get reallocated - even in the same statement like $I13/I16 if possible.
> Regards,
leo
Nick Glencross
> Well. That's it. Just use $I10 ... $I13 and they will stay what they
>
>were. Put a print thereafter for debugging which uses these regs.
>
>
I should have emphasised the oddity a bit better.
'word' has mapped to I16 correctly, and I17 has been used for
$I10..$I12. That's fine.
The problem is that $I13 has become *I16*, not (say) I17, so the line
$I13 = word & 0xff000000
has actually had the side effect of changing 'word'.
Nick
Leopold Toetsch
> The problem is that $I13 has become *I16*, not (say) I17, so the line
> $I13 = word & 0xff000000
> has actually had the side effect of changing 'word'.
Well C<word> and C<$I13> or some such is the same for the compiler. Both
need a Parrot register allocation. If they aren't reused after this
instruction, there isn't any problem to put these into the same
register.
But *if* C<word> is reused after this instruction, then it's of course a
bug. The usage in e.g. F<debug.imc> doesn't indicate any reuse of
C<word>.
Just continue writing the loop and it'll work :)
BTW:
Currently ".param"(s) must be immediately following after the ".sub" line
(no empty line, no comment line) and the return statement is also bogus. see
F<imcc/docs/calling_conventions.pod>
> Nick
leo
Nick Glencross
I've been away from email for the weekend, so sorry for the delay.
Leopold Toetsch wrote:
>Well C<word> and C<$I13> or some such is the same for the compiler. Both
>need a Parrot register allocation. If they aren't reused after this
>instruction, there isn't any problem to put these into the same
>register.
>
>But *if* C<word> is reused after this instruction, then it's of course a
>bug. The usage in e.g. F<debug.imc> doesn't indicate any reuse of
>C<word>.
>
>
Actually, I hadn't appreciated that imcc was seeing that 'word' was
freed up and became available for $I13 mid statement. That's clever.
In the example that I posted things seems to working correctly now
(especially when I use the values as I do in the code that I snipped).
I'll go back to the original version of the code in which I originally
saw the problem. I picked it up exactly because 'word' /was/ being used
(and at the time $I13 was ignored after the line in question).
Thanks for the help Leo.
>BTW:
>Currently ".param"(s) must be immediately following after the ".sub" line
>(no empty line, no comment line) and the return statement is also bogus. see
>F<imcc/docs/calling_conventions.pod>
>
Fixed, thanks.
Nick