Hi all,
I'm trying to figure out a weird bug I'm seeing. I'm hoping it's
something simple in my IR but I can't see anything wrong so I'm
hoping someone here can see something.
I'm using LLVM to compile Java bytecode into native functions.
My code keeps track of the Java local variables in an array of
llvm::Value pointers which get phi'd up at various points. The
function I'm seeing the bug in has a variable "sl" which is
calculated once and used as a loop end condition, ie:
int sp = 0;
int sl = whatever;
while (sp < sl) {
// do stuff
}
The bug is that in my JITted code, sl is calculated as 57, but
after the first iteration it is 0xf900000 despite nothing touching
it as far as I can see.
I attached a copy of the IR, both for the entire function and
for that section with only the blocks that are actually entered
as the function executes. grepping it for local_5 I don't see
anything that would modify it. There is some tracing code too,
the calls to @trace_bytecode and @print_value; the output from
that is also attached.
The bizarre thing is that if I add print the value of local_5
at every bytecode then everything is correct. This is what is
making me suspect a miscompilation.
Thanks in advance for any help!
Cheers,
Gary
Gary Benson wrote:
I attached a copy of the IR, both for the entire function and
for that section with only the blocks that are actually entered
as the function executes. grepping it for local_5 I don't see
anything that would modify it. There is some tracing code too,
the calls to @trace_bytecode and @print_value; the output from
that is also attached.
Actually attached this time...
encodeArrayLoop-part.ir (10.8 KB)
trace (19.1 KB)
encodeArrayLoop.ir.gz (38.7 KB)
Can you please attach IR which can be compiled
to an executable (and shows the problem).
Thanks!
Duncan.
Duncan Sands wrote:
Can you please attach IR which can be compiled
to an executable (and shows the problem).
I've been generating functions using a builder and then
compiling them with ExecutionEngine::getPointerToFunction().
Is there some way I can get compilable IR from that?
Cheers,
Gary
Gordon Henriksen wrote:
> Duncan Sands wrote:
> > Can you please attach IR which can be compiled to an executable
> > (and shows the problem).
>
> I've been generating functions using a builder and then compiling
> them with ExecutionEngine::getPointerToFunction(). Is there some
> way I can get compilable IR from that?
LLVM: llvm Namespace Reference
Cool. Ok, compilable IR is attached. I can't see how I'd make an
executable of it as it contains inlined pointers (the code was never
designed to be dumped) but I compiled it with 'llc test.bc -o test.s'
and it is definitely miscompiled.
I apologise for it being so big, but every time I change the slightest
thing the bug will change or disappear. The section with the error in
is pretty short, however, just 100 or so lines (attached as test.s.part).
From the trace I posted yesterday (also attached), at the top:
lines 2646-2648 print "632: iload"
lines 2649-2652 print "local_5_114 = 57" (the correct value)
From line 2651 you can see that the 57 came from r26.
At the bottom:
lines 4901-4903 print "632: iload"
lines 4904-4907 print "local_5_420 = 261095424" (the junk value)
From line 4906 you can see that the 261095424 also came from r26.
Looking at what happens to r26 in the meantime it seems it's being
used to hold temporary values:
lines 2684 and 2685 calculate an offset into an array which is
then used in line 2687.
line 2703 stores the high word of a pair of inlined pointers,
used in lines 2704 and 2711.
That last one is where the 261095424 comes from.
This is all with svn revision 52213 BTW.
Cheers,
Gary
test.bc.gz (43.6 KB)
trace.part (372 Bytes)
test.s.part (3.99 KB)
test.s.gz (15.7 KB)
What target are you compiling for?
Ciao,
Duncan.
Hi,
lines 2646-2648 print "632: iload"
lines 2649-2652 print "local_5_114 = 57" (the correct value)
which files are these line numbers referring to?
D.
Duncan Sands wrote:
What target are you compiling for?
Ah, sorry, Linux, 32-bit ppc, Fedora 8 specifically.
Cheers,
Gary
test.ll, and the corresponding line numbers.
test.ll.part is test.ll for the section but with unentered blocks
stripped.
Gary Benson wrote:
From the trace I posted yesterday (also attached), at the top:
lines 2646-2648 print "632: iload"
lines 2649-2652 print "local_5_114 = 57" (the correct value)
These two are lines 3993 and 3994 in test.ll.
From line 2651 you can see that the 57 came from r26.
At the bottom:
lines 4901-4903 print "632: iload"
lines 4904-4907 print "local_5_420 = 261095424" (the junk value)
7791 and 7792 in test.ll.
From line 4906 you can see that the 261095424 also came from r26.
Looking at what happens to r26 in the meantime it seems it's being
used to hold temporary values:
lines 2684 and 2685 calculate an offset into an array which is
then used in line 2687.
lines 4048 and 4049 in test.ll.
line 2703 stores the high word of a pair of inlined pointers,
used in lines 2704 and 2711.
The top half of the 261101980 in lines 4074 and 4075.
Cheers,
Gary
test.ll.gz (55.5 KB)
test.ll.part (11.6 KB)