[llvm-commits] CAST patch committed

[Reid Spencer]

On Mon, 2006-11-27 at 14:28 -0800, Chris Lattner wrote:
> > 2. Although I tried for two weeks, I was unsuccessful in making LLVM
> > code generation emit the right code for "cast to bool". Currently, the
> > instcombine pass is turning these into "setne X, 0" as is the current
> > HEAD functionality. When the backend can handle a cast to bool  
> > properly
> > (including promotion from MVT:i1 to MVT:i8), then we can remove these.
> > For now, they stay or many tests will break.
> 
> This should be fixed, please let me know if not.

Seems to be mostly working but I have a regression on 176.gcc now. I
don't know the cause. The test is too large to manually reduce. bugpoint
could take a few days to reduce a test case from this and is likely to
turn up nothing anyway (it hasn't identified a single bug for me in the
last few weeks unless I tell it the specific passes that are in error).

> >
> > I also ran the SPEC CINT2000 test suite. Several tests failed but I
> > don't think they are due to the cast patch. Here's the analysis of  
> > those
> > failures:
> >
> > TEST-FAIL: llc /External/SPEC/CINT2000/175.vpr/175.vpr
> > TEST-FAIL: jit /External/SPEC/CINT2000/175.vpr/175.vpr
> > TEST-FAIL: cbe /External/SPEC/CINT2000/175.vpr/175.vpr
> >    These all fail because of a small difference in floating point
> > computation and the
> >    Makefile doesn't define an FP tolerance.
> >    3,4c3,4
> >    < Cost recomputed from scratch is 256.837830.
> >    < Final Placement cost: 256.837
> >    ---
> >> Cost recomputed from scratch is 255.033325.
> >> Final Placement cost: 255.041
> 
> Spec specifies (benchspec/CINT2000/175.vpr/Spec/object.pm) that this  
> test should have a relative tolerance of 0.1, please add it to the  
> makefile.  FWIW, this passes for me on PPC (which doesn't have the  
> X86 FP issues).

Okay.

> 
> 
> > TEST-FAIL: cbe /External/SPEC/CINT2000/176.gcc/176.gcc
> >    There are significant differences in the assembly output, but this
> > test has been
> >    failing similarly on recent (HEAD) nightly tests as well.
> 
> This fails for me because the CBE doesn't implement the stacksave/ 
> restore builtins right.  If someone was interested in doing this, it  
> should be possible to use GCC extensions to implement this.

Is there a PR open for this?

> 
> > TEST-FAIL: jit /External/SPEC/CINT2000/186.crafty/186.crafty
> >    Crash in the X86 code emitter due to inline asm:
> >    lli: X86CodeEmitter.cpp:625:
> > void<unnamed>::Emitter::emitInstruction(const
> >      llvm::MachineInstr&): Assertion `0 && "JIT does not support  
> > inline
> > asm!\n"' failed.
> >    These are coming from FD_ZERO, FD_SET and FD_ISSET macros used in
> > utility.c and
> >    defined as inline ASM in /usr/include/bits/select.h on my machine.
> >
> > TEST-FAIL: cbe /External/SPEC/CINT2000/186.crafty/186.crafty
> >    I'm assuming the CBE didn't like inline ASM either. It produced no
> > output.
> 
> Ok, right.  Can you send me the inline asm used, or just the  
> entire .bc file?

I attached the /usr/include/bits/select.h file from Linux. This is
mostly asm but I thought I'd give you the extra context since there are
compiler differences for it.

The raw bytecode for 186.crafty is also attached.

> 
> >
> > TEST-FAIL: compile /External/SPEC/CINT2000/253.perlbmk/253.perlbmk
> > TEST-FAIL: llc /External/SPEC/CINT2000/253.perlbmk/253.perlbmk
> > TEST-FAIL: jit /External/SPEC/CINT2000/253.perlbmk/253.perlbmk
> > TEST-FAIL: cbe /External/SPEC/CINT2000/253.perlbmk/253.perlbmk
> >    This test doesn't compile on my machine. Note that neither gcc  
> > 4.0.3
> > nor llvm-gcc
> >    compile this test correctly. They both produce the same errors,
> > starting with:
> >    nt_perlmain.c:89: error: 'MAX_PATH' undeclared (first use in this
> > function)
> >
> >    I noted this:
> >    win32.c:13:19: error: tchar.h: No such file or directory
> >
> >    which would seem to indicate that there's something wrong with the
> > configuration as
> >    a win32 file probably shouldn't be compiled on this platform.
> 
> Ok, this is strange.

Yeah. I haven't found a workaround yet. The docs in the SPEC stuff is
scanty at best. I believe I'm setting the configuration right on the
command line, but for some reason it still is defining the
SPEC_CPU2000_NTOS symbol which causes all the win32 related madness.

> 
> > All the other SPEC CINT2000 tests pass. Unfortunately, I can't test
> > CFP2000 because there are build problems related to f95 which I don't
> > have.
> 
> There are 4 C programs in CFP2000.

Yes, I'll hack the makefiles to get results for those too.


> 
> Thanks Reid,

Thank you!

Reid.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: select.h
Type: text/x-chdr
Size: 2753 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20061127/9ab90a3a/attachment.h>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 186.crafty.linked.rbc
Type: application/octet-stream
Size: 304703 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20061127/9ab90a3a/attachment.obj>