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
frontends?
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
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.
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
etc.
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.
Andrew
