On 11/06/2013 06:31 AM, Richard Biener wrote:
On Wed, Nov 6, 2013 at 12:02 PM, Bernd Schmidt <ber...@codesourcery.com> 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! :-)
Andrew
