[llvm-commits] CAST Patch Update (Review Only)
Reid Spencer
rspencer at reidspencer.com
Sun Nov 12 07:36:43 PST 2006
Update:
I left bugpoint running over night. It reduced the problem to a small
test case but I don't see how its related to casting. I also don't see
how the codegen is wrong. The bugpoint stuff is attached if you care to
review. bugpoint finished with:
*** The following function is being miscompiled:
main__ZN9Classfile5printEv_2E_exit
<cbe><gcc>You can reproduce the problem with the command line:
llc -f bugpoint.test.bc -o bugpoint.test.bc.s
gcc ./bugpoint.safe.bc.cbe.c.so bugpoint.test.bc.s -o
bugpoint.test.bc.exe -Wl,-R.
bugpoint.test.bc.exe /proj/llvm/llvm-test-1/MultiSource/Applications/hbd/Sort.class
The shared object was created with:
llc -march=c bugpoint.safe.bc -o temporary.c
gcc -xc temporary.c -O2 -o ./bugpoint.safe.bc.cbe.c.so -shared
-fno-strict-aliasing
Reid.
On Sat, 2006-11-11 at 23:19 -0800, Reid Spencer wrote:
> Chris & Others,
>
> NOTE: Please Don't commit this!
>
> Attached is the latest CAST patch. This passes all llvm/test and
> llvm-test test cases with the exception of MultiSource/Applications/hbd.
> I'm hoping that fresh eyes on this patch can help discover the problem
> because it is a mystery I have not solved in two weeks.
>
> The problem is not a mis-optimization. The unoptimized bytecode fails
> the test as does every permutation of the gccas optimization passes.
> Except for the fact that the nightly test passes this test, I'm
> unconvinced that this is directly related to the CAST patch. Its
> possible that the CAST patch exposes a bug somewhere else.
>
> Below are some details to characterize the problem.
>
> When hbd is compiled in debug mode (-g) it passes. If not it fails. The
> gcc compiled native version shows no valgrind errors. The llc compiled
> version shows 31 valgrind errors (but only in the optimized version). In
> that case valgrind reports:
>
> ERROR SUMMARY: 31 errors from 1 contexts (suppressed: 18 from 1)
> 31 errors in context 1 of 1:
> Use of uninitialised value of size 8
> by 0x8048A40: (within /proj/llvm/llvm-test-1/MultiSource/Applications/hbd/Output/hbd.llc)
>
> This obviously isn't much help. Since these are uninitialized data
> errors, this could account for the difference in behavior.
>
> The output from the hbd program is C++ code. It decompiles a Java class
> into the C++ equivalent. The diff between the native and llc output is
> several examples of this:
>
> 35c35
> < --var4; /*63*/
> ---
> > var4 -= -1; /*63*/
>
> This difference output is one reason why I *do* think the problem could
> be related to the CAST patch or at least some of the signless types
> work. It appears to be doing a sign extension instead of a zero
> extension on a boolean to arrive at the decrement value.
>
> Any help you can provide with reviewing this patch or formulating a
> strategy for finding the bug would be greatly appreciated.
>
> Thanks in advance,
>
> Reid.
>
> FYI: bugpoint has been hopeless at reducing this to anything meaningful.
>
>
>
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
-------------- next part --------------
.text
.align 16
.globl main__ZN9Classfile5printEv_2E_exit
main__ZN9Classfile5printEv_2E_exit:
subl $20, %esp
movl 24(%esp), %eax
.BB1_2: #_ZN9Classfile5printEv.exit
movl (%eax), %eax
movl %eax, 12(%esp)
movl $2, 4(%esp)
movl $1, 8(%esp)
movl $str21, (%esp)
call fwrite
.BB1_1: #_ZN9Classfile5printEv.exit.ret.exitStub
addl $20, %esp
ret
.size main__ZN9Classfile5printEv_2E_exit, .-main__ZN9Classfile5printEv_2E_exit
-------------- next part --------------
; ModuleID = 'bugpoint.test.bc'
target datalayout = "e-p:32:32"
target endian = little
target pointersize = 32
target triple = "i686-pc-linux-gnu"
%struct.FILE = type { int, sbyte*, sbyte*, sbyte*, sbyte*, sbyte*, sbyte*, sbyte*, sbyte*, sbyte*, sbyte*, sbyte*, %struct._IO_marker*, %struct.FILE*, int, int, int, ushort, sbyte, [1 x sbyte], sbyte*, long, sbyte*, sbyte*, sbyte*, sbyte*, uint, int, [40 x sbyte] }
%struct._IO_marker = type { %struct._IO_marker*, %struct.FILE*, int }
%str21 = external global [3 x sbyte] ; <[3 x sbyte]*> [#uses=1]
implementation ; Functions:
declare uint %fwrite(sbyte*, uint, uint, %struct.FILE*)
void %main__ZN9Classfile5printEv_2E_exit(%struct.FILE** %tmp.i) {
newFuncRoot:
br label %_ZN9Classfile5printEv.exit
_ZN9Classfile5printEv.exit.ret.exitStub: ; preds = %_ZN9Classfile5printEv.exit
ret void
_ZN9Classfile5printEv.exit: ; preds = %newFuncRoot
%tmp392.i = load %struct.FILE** %tmp.i ; <%struct.FILE*> [#uses=1]
%tmp394.i = call uint %fwrite( sbyte* getelementptr ([3 x sbyte]* %str21, int 0, uint 0), uint 2, uint 1, %struct.FILE* %tmp392.i ) ; <uint> [#uses=0]
br label %_ZN9Classfile5printEv.exit.ret.exitStub
}
-------------- next part --------------
Found gcc: /proj/install/bin/gcc
Read input file : 'Output/hbd.llvm.bc'
*** All input ok
Initializing execution environment: Running the code generator to test for a crash: <llc>
*** Checking the code generator...
<llc><gcc><program>
*** Input program does not match reference diff!
Debugging code generator problem!
Checking to see if the program is misoptimized when these functions are run through the passes: _ZN11AccessFlags6strlenEv _Z10fatalerroriz _Z12printsignameP9ClassfileP8_IO_FILERPcS3_Pv _Z7pushimmP9Classfile _Z9pushconstP9Classfile _Z7pushimpP9Classfile _Z9pushlocalP9Classfile _Z10storelocalP9Classfile _Z9iinclocalP9Classfile _Z9anewarrayP9Classfile... <34 total>
<cbe><gcc><llc><gcc><program>: still failing!
Checking to see if the program is misoptimized when these functions are run through the passes: _Z9pushbinopP9Classfile _Z8pushunopP9Classfile _Z5doif1P9Classfile _Z6notexpPP3Exp _Z5doif2P9Classfile _Z5docmpP9Classfile _Z8doreturnP9Classfile _Z13dotableswitchP9Classfile _Z10doluswitchP9Classfile _Z5dogetP9Classfile... <17 total>
<cbe><gcc><llc><gcc><program>: still failing!
Checking to see if the program is misoptimized when these functions are run through the passes: _Z10doluswitchP9Classfile _Z5dogetP9Classfile _Z8sig2typePc _Z5doputP9Classfile _Z10invokefuncP9Classfile _Z11docheckcastP9Classfile _Z12doinstanceofP9Classfile _ZN3Exp8toStringEj main
<cbe><gcc><llc><gcc><program>: still failing!
Checking to see if the program is misoptimized when these functions are run through the passes: _Z10invokefuncP9Classfile _Z11docheckcastP9Classfile _Z12doinstanceofP9Classfile _ZN3Exp8toStringEj main
<cbe><gcc><llc><gcc><program>: still failing!
Checking to see if the program is misoptimized when these functions are run through the passes: _Z12doinstanceofP9Classfile _ZN3Exp8toStringEj main
<cbe><gcc><llc><gcc><program>: still failing!
Checking to see if the program is misoptimized when these functions are run through the passes: _ZN3Exp8toStringEj main
<cbe><gcc><llc><gcc><program>: still failing!
Checking to see if the program is misoptimized when this function is run through the passes: main
<cbe><gcc><llc><gcc><program>: still failing!
*** The following function is being miscompiled: main
Checking to see if the program is misoptimized when all blocks are extracted.
<cbe><gcc><llc><gcc><program><timeout>: still failing!
*** Program execution timed out! This mechanism is designed to handle
programs stuck in infinite loops gracefully. The -timeout option
can be used to change the timeout threshold or disable it completely
(with -timeout=0). This message is only displayed once.
Checking to see if the program is misoptimized when these functions are run through the passes: main main_bb_2E_i main_bb23_2E_i main_bb23_2E_i_2E_bb63_2E_critedge_2E_i_crit_edge main_bb30_2E_i main_bb36_2E_i main_bb47_2E_i_2E_ce main_cond_next_2E_i_2E_ce main_bb63_2E_critedge_2E_i_2E_ce main_bb65_2E_i... <445 total>
<cbe><gcc><llc><gcc><program><timeout>: still failing!
Checking to see if the program is misoptimized when these functions are run through the passes: main_bb1616_2E_i_2E_ce main_cond_false1623_2E_i main_bb1630_2E_i_2E_ce main_cond_true1634_2E_i main_cond_false1639_2E_i main_cond_next1643_2E_i_2E_ce main_cond_next1643_2E_i_2E_bb1630_2E_i_crit_edge main_bb1660_2E_i main_bb1665_2E_i_2E_ce main_bb1672_2E_i_2E_ce... <223 total>
<cbe><gcc><llc><gcc><program><timeout>: still failing!
Checking to see if the program is misoptimized when these functions are run through the passes: main_cond_true265_2E_i_2E_i main_cond_true_2E_i257_2E_i_2E_i main_cond_false_2E_i_2E_i_2E_i main_bb287_2E_i_2E_i_2E_ce main_bb292_2E_i_2E_i main_bb305_2E_i_2E_i_2E_ce main_cond_true313_2E_i_2E_i main_cond_true_2E_i234_2E_i_2E_i main_cond_true328_2E_i_2E_i main_bb340_2E_preheader_2E_i_2E_i... <112 total>
<cbe><gcc><llc><gcc><program><timeout>: still failing!
Checking to see if the program is misoptimized when these functions are run through the passes: main_cond_true575_2E_critedge_2E_i_2E_i main_bb588_2E_i_2E_i main_bb594_2E_i_2E_i_2E_ce main_cond_next602_2E_i_2E_i main_cond_true_2E_i90_2E_i_2E_i main_cond_true613_2E_i_2E_i main_cond_next619_2E_i_2E_i_2E_ce main_bb624_2E_i_2E_i main_cond_true628_2E_i_2E_i main_cond_true_2E_i80_2E_i_2E_i... <56 total>
<cbe><gcc><llc><gcc><program><timeout>: still failing!
Checking to see if the program is misoptimized when these functions are run through the passes: main_cond_true728_2E_i_2E_i_2E_ce main_bb742_2E_i_2E_i_2E_ce main_bb742_2E_i_2E_i_2E_bb742_2E_i_2E_i_crit_edge main_cond_next755_2E_i_2E_i_2E_ce main_cond_true758_2E_i_2E_i main_cond_next760_2E_i_2E_i main_bb770_2E_i_2E_i main_bb776_2E_i_2E_i_2E_ce main_cond_next788_2E_i_2E_i main_cond_true801_2E_i_2E_i... <28 total>
<cbe><gcc><llc><gcc><program><timeout>: still failing!
Checking to see if the program is misoptimized when these functions are run through the passes: main_bb813_2E_i_2E_i_2E_bb813_2E_i_2E_i_crit_edge main_bb828_2E_i_2E_i_2E_ce main_cond_true833_2E_i_2E_i_2E_ce main_bb865_2E_i_2E_i_2E_ce main_bb865_2E_i_2E_i_2E_bb865_2E_i_2E_i_crit_edge main_cond_next878_2E_i_2E_i_2E_ce main_cond_true881_2E_i_2E_i main_bb885_2E_i_2E_i_2E_ce main_bb889_2E_i_2E_i_2E_ce main_cond_false895_2E_i_2E_i... <14 total>
<cbe><gcc><llc><gcc><program><timeout>: still failing!
Checking to see if the program is misoptimized when these functions are run through the passes: main_bb885_2E_i_2E_i_2E_ce main_bb889_2E_i_2E_i_2E_ce main_cond_false895_2E_i_2E_i main__Z14decompileblockP9ClassfileP11method_info_2E_exit_2E_i_2E_ce main_cond_true376_2E_i main_bb383_2E_i main__ZN9Classfile5printEv_2E_exit
<cbe><gcc><llc><gcc><program><timeout>: still failing!
Checking to see if the program is misoptimized when these functions are run through the passes: main__Z14decompileblockP9ClassfileP11method_info_2E_exit_2E_i_2E_ce main_cond_true376_2E_i main_bb383_2E_i main__ZN9Classfile5printEv_2E_exit
<cbe><gcc><llc><gcc><program><timeout>: still failing!
Checking to see if the program is misoptimized when these functions are run through the passes: main_bb383_2E_i main__ZN9Classfile5printEv_2E_exit
<cbe><gcc><llc><gcc><program><timeout>: still failing!
Checking to see if the program is misoptimized when this function is run through the passes: main__ZN9Classfile5printEv_2E_exit
<cbe><gcc><llc><gcc><program><timeout>: still failing!
*** The following function is being miscompiled: main__ZN9Classfile5printEv_2E_exit
<cbe><gcc>You can reproduce the problem with the command line:
llc -f bugpoint.test.bc -o bugpoint.test.bc.s
gcc ./bugpoint.safe.bc.cbe.c.so bugpoint.test.bc.s -o bugpoint.test.bc.exe -Wl,-R.
bugpoint.test.bc.exe /proj/llvm/llvm-test-1/MultiSource/Applications/hbd/Sort.class
The shared object was created with:
llc -march=c bugpoint.safe.bc -o temporary.c
gcc -xc temporary.c -O2 -o ./bugpoint.safe.bc.cbe.c.so -shared -fno-strict-aliasing
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bugpoint.safe.bc
Type: application/octet-stream
Size: 86343 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20061112/379cccad/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bugpoint.test.bc
Type: application/octet-stream
Size: 392 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20061112/379cccad/attachment-0001.obj>
More information about the llvm-commits
mailing list