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: [PATCH 0/6] Conversion of gimple types to C++ inheritance (v3)

On 11/06/2013 06:31 AM, Richard Biener wrote:
On Wed, Nov 6, 2013 at 12:02 PM, Bernd Schmidt <> wrote:

Maybe we need to revisit it? As one of those who were not in favour of
the C++ move, can I ask you guys to step back for a moment and think
about - what do all of these changes buy us, exactly? Imagine the state
at the end, where everything is converted and supposedly the temporary
ugliness is gone, what have we gained over the code as it is now?
as_a gains us less runtime checking and more static type checking
which is good.

I still think all this effort is misdirected and distracts us from
making changes that improve gcc for its users.
That I agree to.  Instead of fixing the less than optimal separation / boundary
between frontends and the middle-end, or fixing several other long-standing
issues with GCC we spend a lot of time refactoring things to be C++.
But that was kind of part of the decision (though I remember that we
mainly wanted to convert containters and isolated stuff, not gimple
or trees (I bet that'll be next)).

Of course I don't see contributors of "changes that improve gcc for its users"
now wasting their time with converting code to C++.  That conversion
may slow down those people, but only so much.  It'll get more interesting
with branch maintainance ...

What does it buy us? I won't comment on the merit of other changes, but I will reiterate what I'm doing.

1 - I think the code restructuring to enable the changes I proposed is quite worthwhile. Our includes are a mess and prototypes locations are all over the map. I think this is a worthwhile cleanup that I probably wouldn't be doing otherwise.

2 - I really believe gimple needs a type system different from front end trees, that is my primary motivation. I'm tired of jumping through hoops to do anything slightly different, and I got fed up with it. With a separate type system for gimple, we can rid ourselves of all the stuff that isn't related to optimization and codegen... Could we do this with trees? possibly, but if I'm going to go to the effort of converting the front end tree types into a new or reduced-type subset, I might as well put that effort into something that is more appropriate right from the start.

3 - Trees are very polymorphic and as a result, its difficult to tell where types are being used. By replacing those uses with an actual type, we'll get static type checking which is another improvement. There is only one way to move the middle/back end off of types as trees that I can see. Go through the source base and find all the places which use trees as types, and replace them with an actual type. This can't be done all at once, its too big a job... So I propose a plan which allows a new gimple type and current trees to coexist. Once the conversion is complete we can easily implement a type system that has the features and traits we want.

4 - I realized that if I am going through the entire code base to find all the type locations, its very little extra work to also do the same for decls and expressions. Then we'll have static type checking for those as well.

5 - When done we will be significantly closer to having the ability to create a self contained IL that we can strictly define... That alone seems a worthwhile goal to me. The IL then becomes appropriate for streaming at any point in during compilation. This means any front end or tool can easily generate or consume a gimple stream which opens up numerous opportunities... That is pretty hard to enable today.

Im going to do the initial bits on a branch for the first couple of months, and during that time convert a number of files over to the new gimple interface. Then we can look at it, measure it, comment on it, tweak it, whatever. You can see exactly what we'll be getting into before we fully commit. I think it will be an improvement over what we have today and much easier to work with. If the consensus is that it bites, then we leave it on the branch, and what have we lost? a few months of my time and we've gained some really useful knowledge.

And no, if I can get trees out of gimple, I don't intend to ever touch them again! :-)


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