Hey all,
In case anyone is interested in using the X86 JIT for stuff, here's a
rundown on where it stands. The X86 JIT can currently be used like this:
lli -force-interpreter=false foo.bc <args>
Until the remaining issues, described below, are fixed, the
-force-interpreter switch will default to true. Once things are finished,
it will default to false, so lli will automatically execute stuff with the
JIT (when running on an X86 host). Needless to say, the JIT is _much_
faster than the interpreter.
At this point, everything basically works. I know of no programs which
are incorrectly code generated or fail to run due to the x86 backend.
The code generated is not wonderful, but it does work. There are still a
couple instructions which are not implemented yet (cast ulong -> fp type,
f.e.) but they are apparently not frequently used. :) That said, here is
the status of programs:
Regression/Jello: All work
SingleSource: All work
MultiSource:
Working: health, perimeter, power, treeadd, bisort, voronoi, tsp, em3d
: pi, llubenchmark, etc...
__iob : bh, anagram, fhourstones, burg, sgefa, sim, 181.mcf, ...
other : mst
The __iob problems are because of explicit references to stdin,out,err in
the .c code. The problem is that the headers we're using turns them into
references to an __iob array, which doesn't exist on X86. The _right_ fix
to this is to port glibc to LLVM. A hackish fix would be to use linux
headers instead of sparc headers to compile these programs. Because this
prevents a large number of programs from working, this should be the first
thing to get addressed in the future probably.
The mst problem is due to the fact that we still compile the whole program
at a time, instead of a function at a time. This wasn't relevant to the
code generator (and only affected a single program), so I haven't fixed it
yet.
Note that this is all with the 64 bit/big endian emulation mode, running
Sparc bytecode files.
In the next semester or so, I would like to do a substantial rewrite of
the GCC frontend to fix the numerous problems that we are dealing with due
to the current implementation. This would allow us to have native 32
bit, little endian, bytecode files when working on X86 and having 64 bit,
big endian files on Sparc. It would also fix the type-unsafe problems we
are having, and make it much easier to implement things like varargs
support. That said, I'll have to see how this fits into the plan for the
semester...
The nice thing about this stage is that the backend can now be used as a
good basis for experimentation, in a variety of different ways. The code
could certainly be improved, but also interesting new things could be
implemented in the framework. The number of supported programs should be
enough to support meaningful experimentation now.
-Chris
--
http://llvm.cs.uiuc.edu/
http://www.nondot.org/~sabre/Projects/
