[llvm-commits] CAST patch committed
Chris Lattner
clattner at apple.com
Mon Nov 27 14:28:02 PST 2006
> 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
More information about the llvm-commits
mailing list