Re: Struggle with FOR_EACH_EDGE

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

Hi Nathan,

> Kazu, I hope I have time to look in detail at your investigation, however
> one thing that might be causing a problem is that FOR_EACH_EDGE is an iterator
> that works for a non-constant VEC.  This means there's an extra level of
> indirection that the optimizer cannot remove, unless it completely inlines
> the body of the loop (there might be some cases it can do it without inlining,
> but I suspect not).  I wonder if it is worthwhile implementing FOR_EACH_EDGE
> and FOR_EACH_EDGE_VOLATILE (I want the default, shorter name, to be the
> constant iterator, so that you have to chose to use the non-constant one).

Yes, the iterator that works for a non-constant VEC adds some
overhead.  I am wondering if it's OK to tweak FOR_EACH_EDGE like so

#define FOR_EACH_EDGE (...)                                    \
  if (vec == NULL)                                             \
    /* The vector is empty.  We don't have anything to do.  */ \
    e = NULL;                                                  \
  else                                                         \
    for (/* usual iterator stuff */)

In other words, I am wondering if it's safe to assume that nobody
calls VEC_free during edge vector iteration.  (I know calling VEC_free
sounds crazy, but I want to hear second opinions).  If I am allowed to
put an "if" like this, the optimizers (or slightly reordered ones) can
remove the null check in the loop.

Anyway, there seem to be several things going on.

1. FOR_EACH_EDGE itself could be improved (like above).

2. VRP is not really effective in this case because it is run before
   SRA, meaning it cannot get at as many scalar variables.  (Andrew
   Pinski pointed this out on IRC).

3. VRP does not know that &x->a is nonnull is x is nonnull.  (PR21294)

I'll start with a low hanging fruit.

Kazu Hirata