[Bug c++/78427] New: missed optimization of loop condition

[vanyacpp at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78427

            Bug ID: 78427
           Summary: missed optimization of loop condition
           Product: gcc
           Version: 6.2.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: vanyacpp at gmail dot com
  Target Milestone: ---

Consider the following code:

void and_1(uint64_t const* a, uint64_t* b, size_t n)
{
    for (size_t i = 0; i != n; ++i)
       b[i] = a[i] & b[i];
}

GCC 6.2 (-O2, -mtune=haswell) generates the following code:

and_1:
        xorl    %eax, %eax
        testq   %rdx, %rdx
        je      .L6
.L5:
        movq    (%rdi,%rax,8), %rcx
        andq    %rcx, (%rsi,%rax,8)
        addq    $1, %rax
        cmpq    %rax, %rdx
        jne     .L5
.L6:
        ret

If we change iteration indices from [0..N) to [-N..0), the end condition of the
loop can be simplified. I would prefer the generated code to be like this:

and_1:
        leaq    (%rdi,%rdx,8), %rdi
        leaq    (%rsi,%rdx,8), %rsi
        negq    %rdx
        jnc     .L6
.L5:
        movq    (%rdi,%rdx,8), %rcx
        andq    %rcx, (%rsi,%rdx,8)
        addq    $1, %rdx
        jne     .L5
.L6:
        ret

As you can see the inner loop is 1 instruction shorter (4 instead of 5). Also
this code use CF after neg instruction to check for zero.

The result loop is slightly faster. On my haswell machine it is 2% faster (5956
ms instead of 6087 ms). I expect the gain to be bigger on a in-order CPUs, but
I can not verify this claim.

I believe this optimization can be applied in many cases of array iteration.
The exact performance gain will depend on the operations performed by the loop
body, but I don't see the cases when this transformation can hurt the
performance of the loop.