Re: PATCH: remove bb_ann_d's num_preds field

[Kenneth Zadeck <Kenneth dot Zadeck at NaturalBridge dot com>]

> Hello,
> 
> > On Wed, 2004-09-29 at 07:54, Ben Elliston wrote:
> > > As Jeff Law suggested, this patch removes the num_preds field from the
> > > bb_ann_d structure, saving one integer (about a 16% saving) per
> > > annotation instance.
> > > 
> > > Tested with a bootstrap and regression testsuite run.  Okay for
> > > mainline?
> > > 
> > > Ben
> > > 
> > > 2004-09-29  Ben Elliston  <bje@au.ibm.com>
> > > 
> > > 	* tree-flow.h (struct bb_ann_d): Remove num_preds member.
> > > 	* tree-into-ssa.c (rewrite_into_ssa): Don't set it.
> > > 	(rewrite_ssa_into_ssa): Likewise.
> > > 	* tree-phinodes.c (create_phi_node): Access the number of
> > > 	predecessor edges using EDGE_COUNT() and not num_preds.
> > Cool.
> > 
> > Probably the next thing to figure out is how to map between
> > incoming edges and phi node elements.
> > 
> > One possibility would be to record the index of each edge in its
> > pred/succ vectors.  So given an edge E, we can get the PHI arguments
> > associated with that edge from PHI_ARG_DEF (phi, E->pred_index).  At
> > first glance I tend to lean this direction, though I don't
> > particularly like the idea of enlarging the edge structure and
> 
> you then however do not need to have the edge recorded in phi nodes,
> so this will pay up (at least on trees; on rtl you of course lose a bit,
> but not more than what we used to have before -- indices of the edge simply
> replaces the {pred,succ}_next pointer of the edge.  Also having the
> indices simplifies some operations (like edge removal), since you no
> longer need to look up the position of the edge in the array.
> 
> > keeping the indices up-to-date.
> 
> This in fact is pretty straightforward -- we have only a few functions
> that modify the edges directly (from what I remember from the time I
> wrote the patch to implement this, actually only some 3 or 4 functions
> needed to be changed).
> 
> Also it is quite simple to check that nothing goes wrong (the indices
> can be verified in verify_cfg and failure to keep edges and arguments
> of phi nodes in sync almost surely leads to failure in verify_ssa,
> or if you want to be more thorough, you can still have edges recorded
> in phi arguments with ENABLE_CHECKING).
> 
> Zdenek
I do not see why you need any explicit connection between the phi data
structure and the in-edge data structure. 

I would suggest that you change to the current linked list
representation of the in-edges to use exactly the same vector
representation that you use for the phi-function edges.  This way the
index of the phi function operand becomes the index into the in-edge
and vica-versa.

Since it makes no sense to add or delete operands without doing the
same to the edges, they should stay in sync as long as the phi operands
are created properly initially.  

This will centainly be the most space and time efficient, since there
are no explicit cross connections to maintain or index thru.

Kenny