Created attachment 2007 [details]
working patch for llvm support

This patch adds support for LLVM, both for building game code assemblies, as well as running those in client and server.

It will probably need some work before it could even be considered to go into mainline ioquake3, but it doesn't break compatibility and isn't all that intrusive except for the Makefile changes.

forgot to mention, for building the llvm assemblies, you have got to cross-compile to 'llvm', basically setting PLATFORM=llvm.

It also raises the question:
Is http://www.gnu.org/philosophy/license-list.html#ModifiedBSD generally acceptable for ioquake3? At least it's listed as GPL compatible.

LLVM's license: http://llvm.org/releases/2.5/LICENSE.TXT

We already have BSD-licensed parts in the ioquake3.org sourcecode.
And as you already mentioned, the modified BSD-license and the
LLVM license which is derived from this license is GNU-compatible.
In my eyes there are no license problems.

Created attachment 2010 [details]
patch adding support for game download and basic pure handling

this patch adds
- allow for auto-downloading by the server touching cgamellvm.bc, just like vm/cgame.qvm
- server to tolerate pure checksum on cgame and ui being from a pak containing the respective llvm's (in addition to the pak containing the qvm's)
- client to use pak's containing actually loaded llvm's resp. qvm's in pure checksums

overall this means
- client and server not using llvm's will work as expected (minus some slack regarding what the right pak checksum is, but it trusts the client there anyway)
- client and server after this patch will work as expected in all combinations (minus above mentioned slack)
- a server using llvm's still allows a client before this patch
- a client using llvm's MIGHT work on a pure server before this patch, if qvm and llvm are in the same pak

So I'm understanding: this compiles the existing C code for the DLLs to LLVM's abstract bytecode, which is then used at runtime by having LLVM convert it to native code on the fly?

I'm curious what the performance increase is over the existing QVM JIT...if it's not significant, is this something we really want to merge in?

It might be interesting to convert the existing QVM bytecode to LLVM bytecode on the fly, though, if it gets us new platforms (like ARM) or a significant performance boost. If you have to compile C code, though, you might as well just use the native DLLs.

--ryan.

(In reply to comment #6)
> So I'm understanding: this compiles the existing C code for the DLLs to LLVM's
> abstract bytecode, which is then used at runtime by having LLVM convert it to
> native code on the fly?
that's currently true for x86, x86_64 and ppc 32/64 only, as that's the platforms their JIT currently supports. it is, however, a WIP. so this list may grow.

> I'm curious what the performance increase is over the existing QVM JIT...if
> it's not significant, is this something we really want to merge in?
i still don't have numbers on this. com_speeds is really too coarse granular for meaningful numbers. could try using RDTSC.

> It might be interesting to convert the existing QVM bytecode to LLVM bytecode
> on the fly, though, if it gets us new platforms (like ARM) or a significant
> performance boost. If you have to compile C code, though, you might as well
> just use the native DLLs.
generating LLVM bytecode on they fly would mean also putting the LLVM front-end into ioquake3 and it wouldn't get us new platforms. the bytecode is already portable.

one of the nicer things about LLVM would be more front-ends - like c++. anything GCC can handle.

anyway, this patch may be put on hold, as i don't consider LLVM stable enough. handling of static arrays tends to blow the JIT's memory for compiled function bodies (it's currently a compile-time limit of LLVM to 16M). the JIT is currently also only available for 2 platforms (see above). this might be something for the patches page...

the interface from this patch though, should keep working just fine against later LLVM versions.

(In reply to comment #3)
> It also raises the question:
> Is http://www.gnu.org/philosophy/license-list.html#ModifiedBSD generally
> acceptable for ioquake3? At least it's listed as GPL compatible.
> LLVM's license: http://llvm.org/releases/2.5/LICENSE.TXT

Just in case this was still an issue, the specific LLVM license is listed on that same page (just further down):

http://www.gnu.org/philosophy/license-list.html#NCSA

NCSA/University of Illinois Open Source License 

This license is based on the terms of the Expat and modified BSD licenses. It is a simple, permissive non-copyleft free software license, compatible with the GNU GPL.

This is a nice bit of work and an interesting feature, but I'm not sure of the actual tangible benefits this really brings to the table. QVMs have their faults, but they're not all that bad, generally speaking. To me this is something that should be listed on the patches page on the website, if it's going to go anywhere.

Created attachment 2806 [details]
rebased and updated LLVM patch

For anyone who cares, I rebased and updated the patch to work with more recent ioquake3 (rev ~1900?) and LLVM 2.9.

It works for me, but doesn't offer any speed-ups. I suppose it could be useful for a full game mod.