[Bug c++/99470] New: Convert fixed index addition to array address offset

[Bug c++/99470] New: Convert fixed index addition to array address offset

[redbeard0531 at gmail dot com]

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

            Bug ID: 99470
           Summary: Convert fixed index addition to array address offset
           Product: gcc
           Version: 11.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: redbeard0531 at gmail dot com
  Target Milestone: ---

These two functions do the same thing but f() is the cleaner source code
(especially when arr is a std::array) while g() generates better code:

https://gcc.godbolt.org/z/vTT399

#include <cstdint>

inline int8_t arr[256];

bool f(int a, int b) {
    return arr[a+128] == arr[b+128];
}

bool g(int a, int b) {
    return (arr+128)[a] == (arr+128)[b];
}

f(int, int):
        sub     edi, -128
        sub     esi, -128
        lea     rax, arr[rip]
        movsx   rdi, edi
        movsx   rsi, esi
        movzx   edx, BYTE PTR [rax+rsi]
        cmp     BYTE PTR [rax+rdi], dl
        sete    al
        ret
g(int, int):
        lea     rax, arr[rip+128]
        movsx   rdi, edi
        movsx   rsi, esi
        movzx   edx, BYTE PTR [rax+rsi]
        cmp     BYTE PTR [rax+rdi], dl
        sete    al
        ret

In addition to only doing the +128 once, it also ends up being completely free
in g() because the assembler (or linker?) folds the addition into the address
calculation by adjusting the offset of the rip-relative address. In the godbolt
link, you can see that when compiled to binary, the LEA instruction uses the
same form in both f() and g(), so the addition really is free in g().

[Bug rtl-optimization/99470] Convert fixed index addition to array address offset

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
these two code are not equivalent at all due to overflows and such.

[Bug rtl-optimization/99470] Convert fixed index addition to array address offset

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |INVALID

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
These functions have the same code gen though:
inline signed char arr[256];

bool f(unsigned long a, unsigned long b) {
    return arr[a+128] == arr[b+128];
}

bool g(unsigned long a, unsigned long b) {
    return (arr+128)[a] == (arr+128)[b];
}

----- CUT -----
The reason why int is not equivalent because signed integer overflow is
undefined plus doing the math in 64bit or 32bit would cause a huge difference
in some cases.

[Bug rtl-optimization/99470] Convert fixed index addition to array address offset

[pinskia at gcc dot gnu.org]

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

--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Andrew Pinski from comment #2)
> The reason why int is not equivalent because signed integer overflow is
> undefined plus doing the math in 64bit or 32bit would cause a huge
> difference in some cases.
The cases is if a/b are negative.

[Bug rtl-optimization/99470] Convert fixed index addition to array address offset

[redbeard0531 at gmail dot com]

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

Mathias Stearn <redbeard0531 at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |UNCONFIRMED
         Resolution|INVALID                     |---

--- Comment #4 from Mathias Stearn <redbeard0531 at gmail dot com> ---
Yes, but I believe any case where they would access different addresses would
be UB overflow in f(), making it valid to turn f() into g(), especially if you
used an internal lowering which sign extended index to pointer width and had
defined wrapping semantics. I'll note that clang already generates identical
code for f() and g() https://gcc.godbolt.org/z/j897sh, although I think gcc has
better codegen at least for g().

Also, my example was perhaps oversimplified. My indexes were actually int8_t
(which is why I'm indexing into a 256-element array), so due to int promotion,
overflow is actually impossible. However, with int8_t arguments, gcc generates
even worse code for f(), doing the sign-extension twice for some reason (8 ->
32 -> 64): https://gcc.godbolt.org/z/5r9h89


(I hope it isn't a faux pas to reopen the ticket, but I think I've provided
enough new information that this warrants another look)