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/07/2013 05:08 AM, Richard Biener wrote:

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.

Well, this first phase is a transitional one... If it were possible, I'd change them all at once to not use a tree... but I don't think that is feasible. There is too much to find and change, and the source base is constantly changing. We can't just freeze the base for a year. so until I can get them all changes, they have to act like trees and interact like trees, so we make them trees under the covers. Short term pain and discomfort...

If it helps, during the transition you can view it as replacing trees with oddly named tree subclasses which provide static type checking instead of run time GIMPLE_CHECK() calls :-)

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

Im talking about changing the type gimple statements refer to, and also what decls and expressions will refer to... making that the gimple_type.

Today, thats a TREE_TYPE tree. During the transition period this gimple_type is indeed a tree under the covers.. so that all the existing code can work even if it hasnt been converted yet. Once everything is converted, then gimple_type has the tree removed from its declaration and we replace it with the bits we need/want... and it will no longer function as a tree.. gimplification will create these from the trees the front end created.

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
I meant any point where we are in gimple... Thats the only point we really care about. Once control is passed to the middle end. No plans to touch GENERIC at all... in fact, GENERIC and 'tree' will become true synonyms when I'm done, because gimple wont have any trees in it anywhere. And rtl will also refer to gimple nodes. It just wont matter what warts are in trees.
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
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.

That is part of the experiment. RIght now I don't know for sure what the real issues will be. I learned a valuable lesson long time ago... measure a problem to determine the cause rather than assume you know where it is. This process will show exactly where there are entanglements are that need to be dealt with. It may be that by the time stage 1 rolls around, I will have identified a few other things that really need to be addressed first. And then I'll then work to address them.

Fold is indeed one of them, but that is one of the reasons why there is also a plan in motion (sort of) to reduce the folding in the front end to a bare minimum... and either have its own minimal folder, or provide an interface through gimplification to a gimple folder to do what it needs. This is all in the original document.

The operating theory is that front ends can do whatever the do today, and the gimplification process will turn trees into whatever gimple object is needed: expr, decl, type, whatever. Today, gimplification only addresses turning tcc_statement trees into gimple statements. What I am proposing effectively does this for all the rest of the tree class nodes.

  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' ;)

Certainly at the beginning when I have to mimic trees there will be a base gimple_operand of some sort which is effectively a 'typed' node... It's required for compatibility. But once trees are no longer required, we are then free to change this. The definition of a gimple_stmt can remove the operand array of 'like objects' (ie trees), and replace it with more context..

One possibility is that gimple_assign could be expanded to have multiple forms of statically typed operands inheriting from the gimple_assign class... ie.
decl = const,
decl = decl op const (or possibly just decl = gimple_2op_expr or some such thing.. i dont know what gimple_exprs will look like yet)
decl = decl
mem_expr = const
and whatever else is needed. This will help define and enforce a formal definition of the gimple IL...

There are other options, but which one to use would be best determined once we have a handle on the other gimple objects and, more importantly, the ability to change their behaviour.


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