This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Push GENERIC farther into C/C++ front ends.
Steven Bosscher wrote:
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.
Yes.
However, I am gradually coming to the opinion that if/when we merge the
C and C++ front ends the operation will be more like "delete the C front
end and add C support to G++" than "squish these two pieces of code
together". The pieces that will actually move are probably those
relating to GNU C extensions and K&R stuff. Things like the slightly
different rules for pointer conversions will just to into the
appropriate places in G++.
What does an unlowered C++representation give you on top of that?
The ability to talk about the program at the level that the programmer
understands. Like "this virtual function call might not be safe" rather
than "this pointer to a function you're accessing through this array
might not be safe".
Perhaps there is a way to annotate GENERIC such that you still preserve
that information?
Perhaps -- but I doubt it. We've thought about this a lot.
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.
I'd use the word "modular", but I understand your point. However, being
modular is just as good for free software as proprietary software. For
example, G++ used to be a lot less modular, which made it impossible to
connect it to the SGI back end. Making it more modular was part of the
process of getting the Open64 technology available. If G++ had been
even more modular, that would be even easier.
As Gaby says, there are lots of people out there using other approaches
precisely because G++ can't be used in these ways. Attracting those
projects to G++ is part of what we should be trying to do.
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?
Let's not rehash that particular debate; there's extensive discussion in
the archives. Basically, GCJ and G++ went in different directions, and
tree-ssa ended up using the GCJ way. I'm not particularly concerned
about what the nodes are named; if building a SWITCH_EXPR directly
helps, and you can still figure out what the original source looked like
from that, it's fine by me. That's not lowering; that's just changing
spelling.
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.
Well, if generating GENERIC made it 50% faster, say, that would be nice.
But, in other compilers, the lowering phase is nowhere near that much
of the cost -- and it won't be here either if we do it right. I think
that before we give up important functionality, we need to be convinced
that there is going to be a huge win.
--
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com