> >> 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
On Sun, 2 May 2004, Patrick Flanagan wrote:> 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:Nope. Right now LLVM doesn't have real support for source-level debugging. There is a debugger *started*, but it needs substantial work before it can be usable, and the C front-end cannot produce debug information yet. If you're interested in the debugger, it is discussed here: http://llvm.cs.uiuc.edu/docs/SourceLevelDebugging.html Sorry! -Chris -- http://llvm.cs.uiuc.edu/ http://www.nondot.org/~sabre/Projects/
I was able to run through all the C/C++ benchmarks in SPEC using LLVM. I'm on OS X 10.3.3. I did a quick comparison between LLVM (latest from CVS as of 4/27) and gcc 3.3 (Apple's build 20030304). For simplicity's sake, the only flag I used was -O3 for each compiler and I was using the C backend to generate native code for PPC. Most of the LLVM results were close to gcc performance (within 5%), but a few of the tests caught my eye. 164.gzip ran about 25% slower on my system using LLVM versus gcc. As you said, source level debugging information wasn't available for the LLVM binary but from looking at a profile of the code, there are two functions that take up a moderate amount of time (zip and file_read) in the LLVM binary but these functions are not in the profile of the gcc code. Is it likely that gcc would have inlined these? file_read is relatively small, but zip is a little bigger. I tried to test this theory by manually editing the gzip code to inline those two functions, eg inline int zip( ... inline int file_read ( .. but when I profiled that new code, it still had those two functions in the profile. Does LLVM support inlining (or am I am idiot and tried to do it manually wrong)? Patrick On May 2, 2004, at 10:40 PM, Chris Lattner wrote:> On Sun, 2 May 2004, Patrick Flanagan wrote: >> 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: > > Nope. Right now LLVM doesn't have real support for source-level > debugging. There is a debugger *started*, but it needs substantial > work > before it can be usable, and the C front-end cannot produce debug > information yet. If you're interested in the debugger, it is discussed > here: > http://llvm.cs.uiuc.edu/docs/SourceLevelDebugging.html > > Sorry! > > -Chris > > -- > http://llvm.cs.uiuc.edu/ > http://www.nondot.org/~sabre/Projects/ > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://mail.cs.uiuc.edu/mailman/listinfo/llvmdev >