[llvm-commits] CAST Patch Update (Review Only)

[Reid Spencer]

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 at cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits