[LLVMdev] Testing LLVM on OS X

Chris Lattner sabre at nondot.org
Sat May 8 19:22:01 PDT 2004


On Sat, 8 May 2004, Patrick Flanagan wrote:
> >> Interesting. Now that you mention it, I do recall thinking the loops
> >> that llvm generated looked a bit different than the gcc loops. I'll go
> >> back and take another look, but this might explain some of that
> >> discrepancy.
> >
> > I'll try to put together a "solution" for this some time in the near
> > future.  Since right now we depend on the CBE for performance, and
> > because
> > so many people use GCC, we really are REQUIRED to cover for this if we
> > want to provide competitive performance.  I imagine that this should
> > improve loop-intensive codes substantially.

> What is the rationale for doing the llvm code -> c backend code ->
> compile that thing anyway? If the person specifies that -native-cbe,
> why not just compile the code as is?

I'm not sure I understand what you mean?  Why not just compile it with GCC
natively?

> >> inlining stuff
>
> I did play around with the inlining threshold to make file_read and zip
> get inlined in more spots. This didn't make any difference though, so
> the main problem seems to be the loops as you pointed out in last
> email. Wouldn't this be a non-issue if the -native-cbe flag just meant
> compile the code given rather than going through llvm code and the c
> backend?

Well the whole idea of LLVM is to lots of interesting interprocedural
optimizations (which GCC can not do).  If you look at the X86 world where
this loop issue is less of a problem, we can speed up some programs (like
179.art) by about 2x over native GCC, and can get 20-40% speedups on quite
a few programs.  Also, we are only starting to add some of the important
optimizations and analyses that will really make LLVM shine.

The problem is just that our native code generators either don't exist
(for PPC) or are not yet quite competitive (on X86), though we are making
progress and getting closer all of the time.

I must say that I would MUCH rather work on making LLVM better than to add
hacks to work around GCC's deficiencies (the Intel compiler has no problem
groking the LLVM produced C code, for example), but there is no way we
will get decent PPC performance until we have a native code generator for
it or can convince GCC to do reasonable things.

-Chris

-- 
http://llvm.cs.uiuc.edu/
http://www.nondot.org/~sabre/Projects/




More information about the llvm-dev mailing list