Re: Push GENERIC farther into C/C++ front ends.

[Steven Bosscher <s dot bosscher at student dot tudelft dot nl>]

On Wednesday 16 June 2004 08:52, Mark Mitchell wrote:
> Andrew Pinski wrote:
> > I would disagree with this as we are first a compiler and then a source
> > to use for other purposes.  In fact generating GENERIC first will speed
> > up the compiler so I (as an employee of Apple) will very much like to
> > replace the whole front-ends with ones which produce GENERIC right
> > away for compile time reasons.
>
> I strongly disagree and, as a maintainer of the C++ front end, I would
> oppose very strongly any patch that did that.

Hmm, so does that mean that, given that other plan of merging the C
and C++ front ends, you also strongy oppose to such a patch for C?
I mean, it would be much harder to do if the C and C++ front ends
would diverge more.


> At the same time, CodeSourcery is very much interested in improving the
> speed of G++ and has a customer who has requested that we do what we can
>   in that regard.  We think there are plenty of ways to do that without
> fundamentally limiting the usefulness of the G++ front end in
> non-compilation contexts.

The question is, does such a patch really limit the usefulness of G++?
I don't know what kind of source analyses you'd do with just the front
end, but syntax analysis is still there, and you still have the semantics
of your program expressed in a tree.
What does an unlowered C++representation give you on top of that?
Perhaps there is a way to annotate GENERIC such that you still preserve
that information?


> There are already worked examples that demonstrate that you can build a
> C++ compiler where the translation from a C++-specific representation to
> a representation at the level of GENRIC is very efficient.

1) Those front ends you refer to are meant to be portable, because
   the end product is just the front end.  It must be portable if
   you're going to sell it as a product.  For G++ I think it's not
   the same.  G++ does not have to be portable to other compilers,
   it's part of GCC.  Just because it is _possible_  doesn't mean
   it is also desirable.

2) What you want is a representation that is as close as possible
   to the original source code.  I think you should not use trees
   for that.  I guess trees were always intended to be extendable
   to language specific purposes, but perhaps C++, and also the C
   front end in recent releases, take this a bit too far.  What's
   the point in having SWITCH_EXPR and SWITCH_STMT, for example?

If making the front end produce GENERIC really also makes it much faster
(which of course remains to be seen), then I'd really like to hear some
stronger arguments against it than that we have to fulfill requirements
for third party source analysis tools.

Gr.
Steven