Possible miscompilation?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

Possible miscompilation?

Gary Benson
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

--
http://gbenson.net/
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Possible miscompilation?

Gary Benson
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...
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

encodeArrayLoop-part.ir (10K) Download Attachment
trace (20K) Download Attachment
encodeArrayLoop.ir.gz (53K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Possible miscompilation?

Duncan Sands
In reply to this post by Gary Benson
Can you please attach IR which can be compiled
to an executable (and shows the problem).

Thanks!

Duncan.
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Possible miscompilation?

Gary Benson
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

--
http://gbenson.net/
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Possible miscompilation?

Gordon Henriksen-3
On 2008-06-11, at 13:16, Gary Benson 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?


http://llvm.org/doxygen/namespacellvm.html#a322

— Gordon


_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Possible miscompilation?

Gary Benson
Gordon Henriksen wrote:

> On 2008-06-11, at 13:16, Gary Benson 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?
>
> http://llvm.org/doxygen/namespacellvm.html#a322
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

--
http://gbenson.net/

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

test.bc.gz (59K) Download Attachment
trace.part (401 bytes) Download Attachment
test.s.part (4K) Download Attachment
test.s.gz (21K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Possible miscompilation?

Duncan Sands
What target are you compiling for?

Ciao,

Duncan.
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Possible miscompilation?

Duncan Sands
In reply to this post by Gary Benson
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.
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Possible miscompilation?

Gary Benson
In reply to this post by Duncan Sands
Duncan Sands wrote:
> What target are you compiling for?

Ah, sorry, Linux, 32-bit ppc, Fedora 8 specifically.

Cheers,
Gary

--
http://gbenson.net/
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Possible miscompilation?

Gary Benson
In reply to this post by Gary Benson
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

--
http://gbenson.net/

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

test.ll.gz (76K) Download Attachment
test.ll.part (11K) Download Attachment