Of Bounties and Mercenaries

[Chris Lattner]

On Tue, 6 Apr 2004, Daniel Jacobowitz wrote:
> On Tue, Apr 06, 2004 at 09:07:48AM -0500, Chris Lattner wrote:
> > On Tue, 6 Apr 2004, Robert Dewar wrote:
> >
> > > Chris Lattner wrote:
> > > > Andrew Pinski wrote:
> > > >
> > > >>The other problem with this is that "Modern" "Standard" C++ has the
> > > >>following problems:
> > > >>1. Makes a mess out of simplifying code from the compiling when the
> > > >>compiler is being miscompiled itself.
> > > >
> > > >
> > > > Huh?
> > >
> > > If you really don't understand the above point 1, that's surprising.
> > > Have you ever actually worked through problems in a self-compiling
> > > bootstrapped compiler? Or are you just arguing language merits?
> >
> > No, I just can't parse the english statement.  Can Andrew or someone else
> > restate?
>
> Sure: I believe what Andrew is saying is that when you have a failure
> in the stage2 compiler, i.e. a miscompiled compiler, it becomes
> substantially harder to diagnose and minimise.
>
> Whether that's true or not I don't know.  It's plausible.

Ah, well I think there are two issues here.  First, bootstrapping is just
one of many tests for compiler correctness that should be done.  Many
other programs should be tested regularly in addition to the compiler
bootstrapping itself.  Currently, GCC exercises the C++ front-end very
little in a bootstrap.  I actually think that making the bootstrap be more
interesting is better: it flushes out more bugs earlier.  That said, I
really don't think there is any good substitute for doing regular
regression test runs and "program tests" (ie, compile and test a whole
bunch of random programs).

Second, I think that tracking down miscompilations is more difficult in
GCC than needbe due to lack of tools.  For example, we have a nifty tool
called bugpoint: http://llvm.cs.uiuc.edu/docs/CommandGuide/bugpoint.html
which takes a program being miscompiled and identifies the compiler pass(es)
causing the problem and reduces the input program down to a loop nest
being miscompiled, automatically.  For other types of problems (e.g.
compiler crashes/aborts) it can often narrow down the testcase to a few
instructions that trigger the problem.

I believe that using a HLL has *many* advantages compared to a low-level
language like C.  Writing higher-level code reduces the number of silly
bugs that creep in.  Using higher-level abstractions makes it easier to
design the compiler from a high-level.  Using a language that makes it
easy to use the right datastructure for a particular job means it's more
likely to be used, etc.  Even simple language features like namespaces
make it much easier for our external users to build tools that interface
with our code.  Finally, using a HLL makes the developers more productive.

In short, our experience using C++ in LLVM has been nothing but positive.

-Chris

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