Re: [patch] basic-block.h: Speed up FOR_EACH_EDGE.

[Kazu Hirata <kazu at cs dot umass dot edu>]

Hi Jeff,

> #define FOR_EACH_EDGE (EDGE, ITER, EDGE_VEC)
>   {
>     for (ITER = ei_start (EDGE_VEC), unsigned int __vec_len = ITER.len;
>          ei_cond (ITER, &EDGE, __vec_len);
>          ei_next (&ITER))
> 
>   }

While I understand your concern, doesn't your approach expose
__vec_len even more if you have to have a user define this variable?
Plus, having to declare two things, an iterator object and this length
variable, seems to tedious.  Whenever I see an iterator, I expect that
all I have to do is to declare an iterator obejct, give it to
FOR_EACH_EDGE, and everything magically works (as long as I don't mess
with a container that I am iterating over).

Can we proceed just with a documentation?

If we look at various data structures, there are a lot of things that
we wish to hide, but C doesn't have access control.  So certain things
have to be handled with our own care, not grammar of a language with
access control.  Maybe we can name the variable in question
"initial_length" with a good comment right above it?

Alternatively, shall we create a separate edge iterator with three
variables, two from edge_iterator and new variable "length"?  We could
name the new data structure edge_readonly_iterator or something.

> > On a serious note, if people really want to use FOR_EACH_EDGE while
> > adding an edge and do not want to have two versions like FOR_EACH_EDGE
> > and FOR_EACH_EDGE_ADDOK, we can still speed up FOR_EACH_EDGE.
> > Specifically, we can remove check "if (e == NULL)" because any edge in
> > an edge vector is supposed to be nonnull.
> I doubt anyone wants to do this :-)  If they do, then they can use the
> slower constructs...

I just tried two things.  One is to remove the vector length check.
The other is to remove the edge null check.  While the former shows a
measurable speed-up, the latter doesn't seem to.  I guess this is
because the removal of the vector length check removes one load from
memory and an associated "if" statament, whereas the removal of the
edge null check an "if" statement but not a load.  We have to load the
next edge anyway.  Plus one edge (e == NULL) of the if statement is
never taken, so I guess any decent branch predictor can correctly
predict which edge edge is taken after the first iteration.

Kazu Hirata