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).
