All,
I have just committed the CAST patch as part of the Signless Types work
(PR950). This isn't complete but it is working and it was time to commit
so we can make more incremental patches in the future. There's a few
things you should know:
1. Try not to use the createInferredCast method. It is currently relying
on signedness to make decisions about which cast opcode to use. Follow
up patches will remove these calls or make createInferredCast not depend
on sign of the types.
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.
3. Because of #2, two new tests will fail. These were created to test
the "cast to bool" functionality of the back end. These should be marked
XFAIL because we know there's a problem in the back end. I didn't mark
them XFAIL because I wanted to see if any of the back ends could pass
this to determine if its a general problem or only X86.
The patch passes all SingleSource and MultiSource tests. That is, there
are failures, but those failures don't deviate from the usual X86
failures we see (inline asm, packed, etc.).
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
I couldn't find a good reason for this difference except for a
cumulative rounding
error in the computation of the "Cost".
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.
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.
TEST-FAIL: llc /External/SPEC/CINT2000/252.eon/252.eon
TEST-FAIL: jit /External/SPEC/CINT2000/252.eon/252.eon
TEST-FAIL: cbe /External/SPEC/CINT2000/252.eon/252.eon
These were all crashing in my GCC 4.0.3 stdlibc++ upon memory
allocation
(operator new[]). I tracked this down to an incorrect link of the
program.
The makefiles link it as:
gcc -fno-exceptions Output/252.eon.llc.s -lm -lstdc++ -lm -o
Output/252.eon.llc
However, the correct link line should be:
gcc -fno-exceptions Output/252.eon.llc.s
-L /proj/llvm/cfe/install-1/lib \
-L /proj/llvm/cfe/install-1/lib/gcc/i686-pc-linux-gnu/4.0.1/ \
-lm -lstdc++ -lm -o Output/252.eon.llc
The problem is that when llvm-test links it leaves unresolved
references to
shared libraries around and they get resolved at runtime to the wrong
shared library.
The other thing that could resolve this is to link the .s program
with llvm-gcc.
I tried both approaches and then the program passes.
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.
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.
Reid.
_______________________________________________
llvm-commits mailing list
llvm-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
