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] for PR 18529


Hello,

> > > This is much better written as
> > >
> > > 	if (TREE_CODE (a1) != PLUS_EXPR
> > > 	    || !integer_onep (TREE_OPERAND (a1, 1))
> > > 	    || !operand_equal_p (TREE_OPERAND (a1, 0), a, 0))
> > > 	  return NULL_TREE.
> > >
> > > This avoids allocating tree nodes just to check that "a1 == a + 1".
> >
> > But is a bit weaker (does not handle the case when one of the
> > expressions is x + 1 and the other one x + 2, for example).
> 
> Look more closely! You're not calling "fold" after you call "build2",
> so the operand_equal_p can only return true for tree with a top-level
> AND_EXPR, one of whose operands is integer_onep :>

ooops... I of course intended to call fold there.

> Not as written.  I was thinking in the case of PR/18529 that it might
> be much simpler to rotate the loop at the same time as it is peeled.
> I'm not an expert in such things, but it would appear to be simpler
> to turn "for(a,b,c)" into "a;if(b){do c; while(b)}" in a single step,
> instead of transforming it into "a;if(b)while(b)c;" and hoping that
> later loop analysis will reveal the while iterates at least once?
> There are probably good reasons, which is why I asked.

Well, what you ask for seems to be mostly missunderstanding of the
issue.  We of course turn for(a,b,c) into if(b){do c; while(b)} if it
is possible and useful.  The problem is that when it is done, we should
be able to derive some further information about the number of
iterations of the loop using it.  For example from

for (i = x; i < n; i++)

we do

i = x;
if (n > x)
  {
    do
     {
       i++;
     } while (i < n);
  }

The loop "do {i++;} } while (i < n);" by itself could leave in the first
iteration if n happens to be smaller than initial value of i, which makes
some optimizations impossible.  However in this case we know that this
cannot happen, using the fact that there is the guard outside the loop
that ensures it.

The problem this patch addresses is that fold is too weak to for example
derive that (x + 1) > n && x < n cannot occur, and thus we are unable to
discover that we are able to simplify the conditions for loop exiting
in the first iteration.

Zdenek


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