Re: LTO, LLVM, etc.

[Mark Mitchell <mark at codesourcery dot com>]

Steven Bosscher wrote:

> What makes EDG so great is that it represents C++ far closer to the
> actual source code than G++ does.

I know the EDG front-end very well; I first worked with it in 1994, and
I have great respect for both the EDG code and the EDG people.

I disagree with your use of "far closer" above; I'd say "a bit closer".

Good examples of differences are that (before lowering) it has a
separate operator for "virtual function call" (rather than using a
virtual function table explicitly) and that pointers-to-member functions
are opaque objects, not structures.  These are significant differences,
but they're not huge differences, or particularly hard to fix in G++.

The key strengths of the EDG front-end are its correctness (second to
none), cleanliness, excellent documentation, and excellent support.  It
does what it's supposed to do very well.

> It would be good for G++ to have
> a representation that is closer to the source code than what it has
> now.

Yes, closing the gap would be good!  I'm a big proponent of introducing
a lowering phase into G++.  So, while I might disagree about the size of
gap, I agree that we should eliminate it. :-)

> I'd be surprised if there a compiler exists that runs optimizations
> on EDG's C++ specific representation. I think all compilers that use
> EDG translate EDG's representation to a more low-level representation.

I've worked on several compilers that used the EDG front-end.  In all
cases, there was eventually translation to different representations,
and I agree that you wouldn't want to do all your optimization on EDG
IL.  However, one compiler I worked on did do a fair amount of
optimization on EDG IL, and the KAI "inliner" also did a lot of
optimization (much more than just inlining) on EDG IL.

Several of the formats to which I've seen EDG IL translated (WHIRL and a
MetaWare internal format, for example) are at about the level of
"lowered" EDG IL (which is basically C with exceptions), which is the
form of EDG IL that people use when translating into their internal
representation.  In some cases, these formats are then again transformed
into a lower-level, more RTL-ish format at some point during optimization.

I'm not saying that having two different formats is necessarily a bad
thing (we've already got Tree and RTL, so we're really talking about two
levels or three), or that switching to LLVM is a bad idea, but I don't
think there's any inherent reason that we must necessarily have multiple
representations.

My basic point is that I want to see the decision be made on the basis
of the effort required to achieve our goals, not on our opinions about
what we think might be the best design in the abstract.  In other words,
I don't think that the fact that GCC currently uses the same data
structures for front-ends and optimizers is in and of itself a problem
-- but I'm happy to switch to LLVM, if we think that it's easier to make
LLVM do what we want than it is to make Tree-SSA do what we want.

-- 
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com
(916) 791-8304