This is the mail archive of the gcc-patches@gcc.gnu.org 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: remove bb_ann_d's num_preds field


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


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