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/
