A new and improved C frontend is now available for experimentation. This
is a C frontend that is based on the GCC AST representation as opposed to
the old frontend which came from the RTL representation (which lost a lot
of type information and caused other problems).
I am still working on the new front-end, but it is remarkably stable for
being so new. If you are interested in playing with it, the binary is
located here: /home/vadve/lattner/local/x86/llvm-gcc/bin/gcc
(Note that you will need to set your LLVM_LIB_SEARCH_PATH environment
variable to "/home/vadve/lattner/local/x86/llvm-gcc/bytecode-libs/"
for
gccld to find "standard" libraries like libc).
So far, I have tested the new C frontend on test cases in
test/Programs/SingleSource. Without exception, all single source test
cases pass when run with the C backend. I expect that many other
testcases work as well, but if you run into any problem, _please let me
know_.
Note that this front-end generates llvm code that has a significantly
different "flavor" than the old one. In particular, it (currently)
generates code for a 32-bit little-endian target (linux-x86), whereas the
old one generated code for a 64-bit big-endian target (Sparc v9). To
support this, the llvm bytecode and assembly formats have been extended to
capture what flavor they are (You can get access to this information
through methods in the Module class).
Another important note is that the code generated will not neccesarily
work with Jello (the X86 JIT) and LLC: the C frontend now generates
"switch" instructions, which neither of them handle (I updated LLI and
the
CBE to support them already, the other two will be updated eventually).
The advantages of the new front-end are three fold: first it generates
code that is much closer to the input .c program. In particular, if you
compile your .c file with the -S option, the LLVM code generated almost
directly corresponds to the input (few optimizations have been performed),
including the names of automatic variables. This should help people who
try to write testcases, but the optimizer deletes all their code.
The second major advantage of the new frontend is that the generated code
is much more type-safe, making the level-raise pass unneccesary, and
should make LLVM analyses more accurate.
The third major advantage of the new frontend is that it is configured for
a particular system as a "native" compiler, instead of a cross
compiler.
This means that when we compile programs under linux, it will use the
linux header files. When compiling under sparc (when I get around to
configuring the compiler for it), it will use the sun header files. While
not an obvious advantage, this means that the JIT and CBE work _much_
better on linux now than they ever have.
-Chris
--
http://llvm.cs.uiuc.edu/
http://www.nondot.org/~sabre/Projects/
