This is the mail archive of the gcc@gcc.gnu.org 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: Putting C++ code into gcc front end


Geoff Keating wrote:-

> Yes, I completely agree.  In particular, we currently represent types
> and statements/expressions using trees, and I believe it's never the
> case that you can substitute one for the other (and what would that
> mean, anyway?); so why don't we have completely distinct type_tree and
> expr_tree data structures?
> 
> Of course, this has been mentioned several times before, and no-one's
> produced a patch...

I tried to do something far less ambitious: make all trees that point
to IDENTIFIER_NODEs only point to identifier nodes (and nothing else).
Believe me, that was so hard and messy I gave up.  And that's about
1% of the job.  I'm not surprised no-one's seen a patch.

It would be much easier if you didn't have to worry about 6 different
front ends for every dinky little change you make to some tree.  Or
if you had something that documented the quirks of how every field was
used by every front end.  We have nothing close to that.  It's almost
impossible to make significant changes to trees: not only do they
represent everything, but they represent everything in every goddamn
front end.  It's a really nasty situation to be in.

Every front end should have it's own representation, which should be
lowered to something common like GIMPLE that is simple, well-
documented, and yet expressive enough to be useful to everyone.  I
feel we can't make real progress any other way.  Imagine how
maintainable each front-end having its own high-level IR with real
distinct C structs and unions would be.

Neil.


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