Second Update: I ran findmisopt one more time and this time it found something: -mem2reg -instcombine. I'm currently tracking down the misoptimization. It seems to be a little too aggressive in eliminating setcc:
136,139c129,131 < %tmp71 = load ubyte* %tmp70 ; <ubyte> [#uses=1] < %tmp71 = bitcast ubyte %tmp71 to sbyte ; <sbyte> [#uses=1] < %tmp71 = sext sbyte %tmp71 to int ; <int> [#uses=7] < %tmp72 = getelementptr ubyte* %tmp70, long 1 ; <ubyte*> [#uses=1] --- > %tmp71 = load ubyte* %tmp70 ; <ubyte> [#uses=3] > %tmp71 = sext ubyte %tmp71 to int ; <int> [#uses=2] > %tmp72 = getelementptr ubyte* %tmp70, int 1 ; <ubyte*> [#uses=1] 141c133 < %tmp74 = seteq int %tmp71, 1 ; <bool> [#uses=1] --- > %tmp74 = seteq ubyte %tmp71, 1 ; <bool> [#uses=1] 148,149c140 < %tmp78 = seteq int %tmp71, -1 ; <bool> [#uses=1] < br bool %tmp78, label %cond_true79, label %cond_next80 --- > br bool false, label %cond_true79, label %cond_next80 The branch condition should not become "bool false". It needs to test for -1. This unconditional branch causes the output difference. Reid. On Sun, 2006-11-12 at 07:36 -0800, Reid Spencer wrote: > 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@cs.uiuc.edu > > http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits > _______________________________________________ > llvm-commits mailing list > llvm-commits@cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits _______________________________________________ llvm-commits mailing list llvm-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
