[PATCH 0/6] Conversion of gimple types to C++ inheritance (v3)

[Richard Biener]

On Wed, Nov 6, 2013 at 9:56 PM, Andrew MacLeod <amacleod@redhat.com> wrote:
> On 11/06/2013 06:31 AM, Richard Biener wrote:
>>
>> On Wed, Nov 6, 2013 at 12:02 PM, Bernd Schmidt <bernds@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.

True.

> 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.

I'm not sure.  Especially the idea of wrapping everything in a
I'm-not-a-tree-well-but-I-really-still-am scares the hell out of me.
And I put that into the very same basket of things you now complain about.

> 3 - Trees are very polymorphic and as a result, its difficult to tell where
> types are being used.

It's a feature.  Now the type vs. object thing may be something to
change (historically the reason they are entangled is that things
like a vector and a list also were trees - which is a feature).

> 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.

Note that on 'gimple' there are no types ... the types are on the objects
'gimple' refers to and those are 'tree's.  So you'd need to change the
'tree's to have TREE_TYPE not be a 'tree'.  Or simply subclass
'tree' so you can distinguish a tree type from a tree non-type statically
(a bit awkward with the current union setup).

But maybe I'm confusing what you call 'type'.

> 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.

Have fun with dealing with our legacy frontends ;)  Or didn't you
actually mean "any point" during compilation? ... oh, you talk about
GIMPLE.  So no plans for Frontend ASTs aka GENERIC for our legacy
frontends?

> 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.

Before we fully commit we want to see the underlying object changes.
Because I still doubt this all will work out without seriously restructuring
the entanglement of our tree-based frontends and the middle-end
(say "fold").

That is, I still think you are starting this at the wrong end.  You first
need to solve the entanglement issue before you can seriously consider
making any real change to the data structures GIMPLE relies on.

>  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! :-)

Well, I'm betting that you'll re-invent sth like 'tree' just don't
call it 'tree' ;)
You need to transparently refer to constants, SSA names and decls
(at least) as GIMPLE statement operands.  You probably will make
a "gimple statement operand" base class.  Well - that's a 'tree' ;)

Richard.


> Andrew
>