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: [tree-ssa] Syntactic structures

On Sat, Aug 02, 2003 at 07:49:58PM -0400, Diego Novillo wrote:
> > I am mostly decided to postpone the loop optimizer work a bit and
> > instead clean up this mess.  Would someone mind?
> > 
> You will have to be more specific.  The word 'mess' is colorful but
> hardly descriptive.  What is it that you are trying to do?  How is it
> not working?  What do you think is missing?  Loop optimization will
> likely expose limitations in the current framework, but we need more
> specific information to address the problems.
With the current status of things one should keep two representations,
the cfg and the syntax tree, synchronized.  A modification in one 
representation have to update the other representation.  This is redundant.

If I analyze correctly the situation, we keep the tree representation 
in such a shape that the expanders to rtl could work on it in the same 
way they have worked before (tree-ssa).  The CFG at the tree level is 
just an auxiliary representation, and the only thing that matters when 
the CFG is freed, is that the tree structure is in a good shape for 
the expanders.

I think that the word "mess" is here for describing 
- the nesting of syntactic control constructs, 
- the redundant representation of control constructs in trees and in CFG, 
- ... 
IMO this comes from the fact that 
- the CFG is a map over the AST instead of a skeleton,
- the CFG is an auxiliary representation instead of a central representation.

The operations on the CFG are difficult since they have to keep updated 
the underlying AST structure.  What Zdenek proposes is to keep the control 
flow information in the CFG, and make the CFG a central representation.  
This is yet a sort of simplification of the tree structure where all 
the control flow expressions are replaced by the CFG representation.  

The construction of the CFG will cut the tree of a function into 
basic blocks.  This will simplify the work of the expanders, since 
they will keep the CFG information (that has already been translated) 
and will translate only the expressions contained in the basic blocks, 
ie. instead of:

expand_expr (tree t)
  switch (TREE_CODE (t))

we'll have:

expand_function ()
    expand_bb (bb);

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