> > There are two problems with this: 1) there is no JIT for PPC yet, so > LLVM will use the interpreter (which is intolerably slow and has other > issues). 2) Spec compiles the executables in one place and them moves > them to another, but it only copies the shell script and not the > bytecode file, so you get that error message. > > The normal solution to this problem is to link with the llvmgcc > '-Wl,-native' option. This tells llvmgcc to produce a native executable > instead of a shell script, using a PPC backend. I'm sure you immediately > see the problem with this. :) > > The real solution to your problem is in CVS. There llvmgcc supports a > -Wl,-native-cbe option which will use the C backend to create a native > executable for you, and can actually be used to run SPEC successfully. > If you're willing to grab LLVM CVS (details here: > http://llvm.cs.uiuc.edu/docs/GettingStarted.html#checkout ), this is the > best bet.Thanks! Grabbed the latest from CVS and added that linker option to the config file. It looks like it compiles and runs the SPEC tests ok now. Just to make sure I understand how LLVM works, got a few clarifications: 1. The ppc code I'm generating with the -native-cbe is static, correct? 2. Is there a frontend to any of the other gnu compiler collection stuff? Eg g77 or something for compiling fortran code or is c/c++ the focus right now? 3. Does the code that uses the JIT compiler (I know, doesn't currently exist on ppc) currently take advantage of run-time optimization? If I ran the SPEC suite with a JIT compiled version several times, would I except the score to eventually increase at all, depending on what the benchmark does?> > Is anyone currently working on making it generate native ppc code for OS > > X? If not, what would be involved in doing so? I'm new to LLVM, I'd > > appreciate some pointers to some info that might shed some light on > > that. > > There was a group that started working on this, but I believe they got > stalled and are no longer working on it. It will try to get in touch with > them to see where things stand, then get back to you on this. >I only know just enough about compilers to be dangerous, but I'm working on learning more :). If no one else is currently working on this, what would be needed in order to get the JIT compiler up and running on ppc/os x? Is it just a matter of taking some tree/rtl form stuff and emitting ppc code instead of x86 code? Is there code that needs to be ported to os x so it can profile itself? Patrick
On Fri, 30 Apr 2004, Patrick Flanagan wrote:> Thanks! Grabbed the latest from CVS and added that linker option to the > config file. It looks like it compiles and runs the SPEC tests ok now.Great!> Just to make sure I understand how LLVM works, got a few clarifications: > > 1. The ppc code I'm generating with the -native-cbe is static, correct?Yes, it's purely static with the -native-cbe or -native options.> 2. Is there a frontend to any of the other gnu compiler collection > stuff? Eg g77 or something for compiling fortran code or is c/c++ the > focus right now?So far only C and C++ are currently supported. Objective C support is extremely close to working, but I haven't had time to work on it at all, and I don't know objective C very well in any case. :) Fortran, Java, and Ada support has not been tried at all, and are likely to be more work than objc. If you are familiar with GCC, adding support for the other GCC front-ends is not very difficult. It basically amounts to implementing the langhooks that are used to expand the language-specific tree nodes into the appropriate LLVM code. Of all of them, having G77 would be particularly nice, because it would allow us to run the rest of SpecFP, though f2c might be another option if it works very well (I've never tried it before). Long-term we'd like to have a nice F90 front-end, perhaps based on the Cray front-end. If anyone is interested in Fortran, this would be an excellent project. :)> 3. Does the code that uses the JIT compiler (I know, doesn't currently > exist on ppc) currently take advantage of run-time optimization? If I > ran the SPEC suite with a JIT compiled version several times, would I > except the score to eventually increase at all, depending on what the > benchmark does?Nope, not currently. The ultimate goal is to support this, but right now it's not implemented.> I only know just enough about compilers to be dangerous, but I'm working > on learning more :). If no one else is currently working on this, what > would be needed in order to get the JIT compiler up and running on > ppc/os x? Is it just a matter of taking some tree/rtl form stuff and > emitting ppc code instead of x86 code?Basically a new code generator would need to be written. The current X86 code generator (ignoring the experimental instruction selectors) is about 8-9000 LOC (about 4800 SLOC, as reported by sloccount) in the lib/Target/X86 directory, which should give you an idea of how much work it currently is to implement a code generator. The X86 backend also has a bunch of little optimizations in it, so a simple code generator would probably be a lot less code. We are slowly working on developing tools that will reduce this amount of code further, but they won't be ready for some time. I emailed the guys that started working on the PPC backend. My impression is that it is close to working, but they ran into some issues with stack frame layout, and hadn't had time to look into them recently. They are currently trying to get it cleared through their company to release the code, which will allow others to continue their work (cross your fingers :).> Is there code that needs to be ported to os x so it can profile itself?The only thing that LLVM is missing on OS/X (besides a code generator) that I'm aware of is support for dynamic plugin loading (Brian would know more). If you look in lib/Support/DynamicLinker.cpp, you'll see some stuff that is only defined for HAVE_DLOPEN. It would be very handy to get support for OS/X, which doesn't have the dl* family of syscalls. -Chris -- http://llvm.cs.uiuc.edu/ http://www.nondot.org/~sabre/Projects/
> >> Just to make sure I understand how LLVM works, got a few >> clarifications: >> >> 1. The ppc code I'm generating with the -native-cbe is static, >> correct? > > Yes, it's purely static with the -native-cbe or -native options.Is there anything special flagwise that I would need to specify to tell it to include symbol and debug information? I've tried specifying -g but this information still doesn't seem to be included. A quick copy of the build of one of the tests to make sure I've got the flags right: Compiling Binaries Building 164.gzip ref base ppc32_llvm default specmake clean 2> make.err | tee make.out rm -rf gzip gzip.exe *.o core *.err *.out specmake build 2> make.err | tee make.out /Users/patrick/Desktop/LLVM/cfrontend/ppc/llvm-gcc/bin/gcc -c -o bits.o -g -O3 bits.c /Users/patrick/Desktop/LLVM/cfrontend/ppc/llvm-gcc/bin/gcc -c -o deflate.o -g -O3 deflate.c /Users/patrick/Desktop/LLVM/cfrontend/ppc/llvm-gcc/bin/gcc -c -o gzip.o -g -O3 gzip.c /Users/patrick/Desktop/LLVM/cfrontend/ppc/llvm-gcc/bin/gcc -c -o getopt.o -g -O3 getopt.c /Users/patrick/Desktop/LLVM/cfrontend/ppc/llvm-gcc/bin/gcc -c -o inflate.o -g -O3 inflate.c /Users/patrick/Desktop/LLVM/cfrontend/ppc/llvm-gcc/bin/gcc -c -o lzw.o -g -O3 lzw.c /Users/patrick/Desktop/LLVM/cfrontend/ppc/llvm-gcc/bin/gcc -c -o spec.o -g -O3 spec.c /Users/patrick/Desktop/LLVM/cfrontend/ppc/llvm-gcc/bin/gcc -c -o trees.o -g -O3 trees.c /Users/patrick/Desktop/LLVM/cfrontend/ppc/llvm-gcc/bin/gcc -c -o unlzh.o -g -O3 unlzh.c /Users/patrick/Desktop/LLVM/cfrontend/ppc/llvm-gcc/bin/gcc -c -o unlzw.o -g -O3 unlzw.c /Users/patrick/Desktop/LLVM/cfrontend/ppc/llvm-gcc/bin/gcc -c -o unpack.o -g -O3 unpack.c /Users/patrick/Desktop/LLVM/cfrontend/ppc/llvm-gcc/bin/gcc -c -o unzip.o -g -O3 unzip.c /Users/patrick/Desktop/LLVM/cfrontend/ppc/llvm-gcc/bin/gcc -c -o util.o -g -O3 util.c /Users/patrick/Desktop/LLVM/cfrontend/ppc/llvm-gcc/bin/gcc -c -o zip.o -g -O3 zip.c /Users/patrick/Desktop/LLVM/cfrontend/ppc/llvm-gcc/bin/gcc -Wl,-native-cbe -O3 bits.o deflate.o gzip.o getopt.o inflate.o lzw.o spec.o trees.o unlzh.o unlzw.o unpack.o unzip.o util.o zip.o -o gzip gzip.cbe.c:146: warning: conflicting types for built-in function `memcmp' gzip.cbe.c:149: warning: conflicting types for built-in function `fprintf' gzip.cbe.c:181: warning: conflicting types for built-in function `strrchr' gzip.cbe.c:187: warning: conflicting types for built-in function `memcpy' gzip.cbe.c:188: warning: conflicting types for built-in function `memset' specmake options 2> options.err | tee options.out COMP: /Users/patrick/Desktop/LLVM/cfrontend/ppc/llvm-gcc/bin/gcc -c -o options.o -g -O3 LINK: /Users/patrick/Desktop/LLVM/cfrontend/ppc/llvm-gcc/bin/gcc -Wl,-native-cbe -O3 -o options With the same set of flags, gcc includes debug information. Is there anything else I need to add to get LLVM to do this too? Thanks, Patrick
Chris Lattner wrote:> The only thing that LLVM is missing on OS/X (besides a code generator) > >that I'm aware of is support for dynamic plugin loading (Brian would know >more). If you look in lib/Support/DynamicLinker.cpp, you'll see some >stuff that is only defined for HAVE_DLOPEN. It would be very handy to get >support for OS/X, which doesn't have the dl* family of syscalls. > >Hi Chris, If I remember well, Panther (Mac OS X 10.3) has a dlopen (see http://www.linuxworld.com.au/index.php?id=660010615&fp=2&fpid=1). Otherwise, it is provided by the "dlcompat" library (http://www.opendarwin.org/projects/dlcompat/), which is very small. So you can use the dlcompat headers for pre 10.3, and use dlopen for 10.3+. Cheers, -- Sébastien