[LLVMdev] Testing LLVM on OS X
sabre at nondot.org
Tue May 4 20:59:01 PDT 2004
On Tue, 4 May 2004, Patrick Flanagan wrote:
> 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.
Okay, sounds great. Are you using the -native-cbe option? Or are you
running llc -march=c ... and GCC manually?
> 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.
Hrm, I really want to figure this out!
> 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?
It's quite possible. The best way to check is to look at the .s file
produced by GCC and see if they are there. Note that GCC is much more
aggressive abount inlining than LLVM is.
> 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)?
LLVM supports inlining, and you're not an idiot. :) The problem is that
LLVM doesn't "listen" to "inline" hints at all right now. If you would
like to adjust the inlining thresholds, you can pass
-Wa,-inline-threshold=XXX or -Wl,-inline-threshold=XXX to set the
compile-time or link-time inlining thresholds, respectively. These both
default to 200 (which has no units), if you increase it, the inliner will
If you want to see what inlining decisions are being made, pass
-debug-only=inline (with -Wa, or -Wl,) to see what "choices" the inliner
Note that, even without source-level debugging information, you can still
do performance investigation with LLVM. You can either look at the C code
generated by the CBE (which will hurt your eyes: brace yourself), or you
can look at the LLVM code directly, which will be easier to handle (once
you get used to reading LLVM).
I suspect that a large reason that LLVM does worst than a native C
compiler with the CBE+GCC is that LLVM generates very low-level C code,
and I'm not convinced that GCC is doing a very good job (ie, without
Please let me know what you find!
> 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
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
More information about the llvm-dev