[llvm-commits] CAST patch committed

[Chris Lattner]

> 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.

>
> 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).


> 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.

> 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?

>
> 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.

> 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.

Thanks Reid,

-Chris