This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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.


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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]