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




On Thu, 30 Sep 2004, Jeffrey A Law wrote:

On Thu, 2004-09-30 at 01:41, Zdenek Dvorak wrote:
Hello,

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

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.

you still need to know the index of the edge in the vector, so that you are able to find argument on an edge in O(1) (which is basically what we are arguing about here).
I wonder how often we could get the index from out iterator.

ie, how often is it the case that we're doing something like

FOR_EACH_EDGE (e, ei, bb->succs)
 FOR_EACH_PHI in e->dest
   find the argument associated with e

vs finding a PHI argument for an arbitrary edge.

PRE and the new store sinking do this (find phi argument for arbitrary edge),
I'm sure if they were both in the same order, I could transform it to do them in that order.
It just wasn't faster to do it that way at the time.
In fact, i'm pretty sure for most of our transformations, we could make this type of transformation.


Or something similar.  For the first class of uses we ought to be able
to get the index via the FOR_EACH_EDGE code by keeping an index
in the iterator.  In the second case we'd need an index in the edge
itself or something similar.

jeff





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