This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: LLVM/GCC Integration Proposal


On Sat, 19 Nov 2005, Joseph S. Myers wrote:
On Fri, 18 Nov 2005, Chris Lattner wrote:
1. The build system is taught about C++ code.

With toplevel bootstrap this will bootstrap libstdc++ so that the compiler ends up linked with the new libstdc++ not the (in general ABI-incompatible) old one? (This question applies to all projects involving C++ in GCC.)

No, my personal configure-fu is too weak to attempt this, and I haven't dug into the problem yet. I currently depend on there already being both a native C++ compiler (like Ada depends on having a native Ada compiler) and that the libstdc++'s are compatible. This is a deficiency in the current implementation, not something that is unsolvable.


While it has many virtues, LLVM is still not complete, and we are investing in
adding the missing features.  In particular, this system is missing two key
features to be truly useful: debug info support and inline asm support.  Apple
is currently investing in adding both these features, as well as adding vector
support.

What (on any one target of your choice) is the GCC testsuite status when LLVM-enabled, compared to that without LLVM, and are most of the regressions fixed by the addition of debug info, inline asm and vector support?

I'm sorry but I haven't gotten to that point yet. I've been working on the integration project for only about 3 weeks now, so I haven't had a chance to do as much testing as I would like (which is why I suggested not
merging for a month). Basically right now things are working well enough for me to build and run (correctly :) ) several dozen small-to-medium sized GUI apps written in C and ObjC on PowerPC. If you're familar with the Apple Xcode distribution, I've basically been working on apps out of /Developer/Examples. Everything I have tried (which is all of the large programs and many of the small ones) work fine.


I intend to get C++ up and running as well as doing Dejagnu testing before actually merging into the Apple branch.

(Once debug info support is added, the same question applies
regarding GDB testsuite status.)

Clearly, as we bring up debug info support we will use all of the suites to make sure we've done it right! :)


Do you propose annotating testcases for features not supported with LLVM
so they are XFAILed when configured with --enable-llvm?  (XFAIL would be
right for features the compiler should support but LLVM doesn't yet;
UNSUPPORTED for tests of some incidental feature of the current back-end
implementation which it makes sense for replacement infrastructure not to
support.  A switch to LLVM as the default back-end for a target would
require no such XFAILs for that target, though there might be
UNSUPPORTEDs, buggy testcases might be fixed or removed and features might
be removed through the usual deprecation process.  dg-xfail-if and
dg-skip-if with an llvm effective-target keyword are the way to annotate
the tests.)

I don't have any strong plans or feelings on this. My initial idea was to have a staged approach, something like this:


1. Initially the work is done on a branch (e.g. the Apple branch) and must
   be explicitly enabled (e.g. with --enable-llvm).  Implementation of
   missing features continues.  I should note that the patch doesn't tie
   into anything Apple-specific in the Apple branch.
2. When the basics are finished (e.g. inline asm, debug support, vectors),
   I would consider it ready to merge to mainline.  At that point,
   adjusting XFAIL markers would make sense.

The big question is the --enable-llvm configure option. Without an LLVM->GIMPLE or LLVM->RTL translator, it seems impossible to merge LLVM to mainline without the configure option. Having this translator has advantages other than supporting all of the GCC targets: it allows more flexible choice of what is part of LLVM and what isn't. It also allows use the new RTL-based register allocator work when it comes online.

If anyone is interested in working on the translator, it would be a great help. I expect that my hands will be full of various front-end translation and LLVM extension work for the next few weeks, so I personally won't be able to build it for some time.

Finally, I should note that the patch isn't a secret. I'm waiting to merge it in until it is more tested and feature complete... I'm not trying to hide it. If anyone wants a copy, please just let me know and I'll be happy to provide it.

-Chris

--
http://nondot.org/sabre/
http://llvm.org/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]