A question about doloop

A question about doloop

[Revital1 Eres]

Hello,

Doloop optimization fails to be applied on the following kernel from
tescase sms-4.c with mainline (-r 162294) due to 'Possible infinite
iteration
case' message; taken from the loop2_doloop dump. (please see below).
With an older version of gcc (-r 146278) doloop succeeded to be applied
and I appreciate an explanation about the change of behavior.

Thanks,
Revital

The kernel:

  unsigned int i, n = size;
  int changed = 0;

  for (i = 0; i < n; i++)
    {
      const int tmp = *ap++ | (*bp++ & *cp++);
      changed |= *dstp ^ tmp;
      *dstp++ = tmp;
    }

The messages from loop2_doloop dump:

Doloop: Possible infinite iteration case.
Doloop: The loop is not suitable.


Loop 1 is simple:
  simple exit 4 -> 5
  infinite if: (expr_list:REG_DEP_TRUE (ne:SI (and:DI (minus:DI (plus:DI
(ashift:DI (reg:DI 200)
                        (const_int 2 [0x2]))
                    (reg/v/f:DI 194 [ ap ]))
                (reg:DI 168 [ ivtmp.19 ]))
            (const_int 3 [0x3]))
        (const_int 0 [0]))
    (nil))

Re: A question about doloop

[Alexander Monakov]

On Mon, 26 Jul 2010, Revital1 Eres wrote:

> 
> Hello,
> 
> Doloop optimization fails to be applied on the following kernel from
> tescase sms-4.c with mainline (-r 162294) due to 'Possible infinite
> iteration
> case' message; taken from the loop2_doloop dump. (please see below).
> With an older version of gcc (-r 146278) doloop succeeded to be applied
> and I appreciate an explanation about the change of behavior.

This may be due to changes in induction variable selection and the ability of
loop2_doloop to discover number of iterations for different variants of IV
selection (which is not trivial when 'i' variable is eliminated and loop
boundary is expressed with pointer comparison).  See PR32283 [1] audit trail
for an example of a related problem that was discussed before.

It is possible that something is missing in simplify-rtx.c so that 'infinite
if' condition cannot be simplified and proven to be always false.  Zdenek once
had to improve simplify-rtx.c for this reason, as the audit trail shows.

[1] http://gcc.gnu.org/PR32283

Hope that helps,
Alexander