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