[Bug tree-optimization/66261] New: operations that simplify whether the pointers are the same or not (++p;++q;--p;--q)

[Bug tree-optimization/66261] New: operations that simplify whether the pointers are the same or not (++p;++q;--p;--q)

[glisse at gcc dot gnu.org]

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

            Bug ID: 66261
           Summary: operations that simplify whether the pointers are the
                    same or not (++p;++q;--p;--q)
           Product: gcc
           Version: 5.0
            Status: UNCONFIRMED
          Keywords: missed-optimization
          Severity: enhancement
          Priority: P3
         Component: tree-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: glisse at gcc dot gnu.org
  Target Milestone: ---

In the example below, if p and q refer to different objects, the function does
nothing, and if they refer to the same object, it also does nothing. But we
don't manage to optimize it, and I don't know how we could do it (without being
incredibly specific). It might actually be slightly easier at the RTL level for
targets where adding a constant to an integer in memory is a single insn, so it
could be detected that ++q and --p commute. clang++, icpc and sunCC don't
simplify it either.

void f(int&p,int&q){
  ++p;++q;--p;--q;
}

[Bug tree-optimization/66261] operations that simplify whether the pointers are the same or not (++p;++q;--p;--q)

[rguenth at gcc dot gnu.org]

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

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
Interesting ;)

[Bug tree-optimization/66261] operations that simplify whether the pointers are the same or not (++p;++q;--p;--q)

[pcordes at gmail dot com]

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

Peter Cordes <pcordes at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |pcordes at gmail dot com

--- Comment #3 from Peter Cordes <pcordes at gmail dot com> ---
Re: does this show up in real code: not exactly this, but incrementing two
array elements that might or might not be the same location defeats optimizing
an  x++  loop into x += n

From
https://stackoverflow.com/questions/77618348/why-does-gcc-fail-to-reduce-a-loop-that-increments-two-locations-of-the-same-buf

unsigned int getid();
void foo(unsigned int *counter, unsigned int n) {
        unsigned int A = getid();
        unsigned int B = getid();
        for (unsigned int i = 0; i < n; i++) {
            ++counter[A];
            ++counter[B];
        }
}



If the two locations are related so GCC knows they're not the same, 
such as arr[A%4 + 0] and arr[A%4 + 16], it can also optimize.
https://godbolt.org/z/PbeaW8nnE

But it doesn't help to do something like  if (A==B) return;
before the loop so it can't be entered with A==B

Source-level loop fission is required to get good asm (two increments to memory
locations that might be the same or not).