[Bug c/111933] New: memcpy on Xtensa not optimized when n == sizeof(uint32_t) or sizeof(uint64_t)

[Bug c/111933] New: memcpy on Xtensa not optimized when n == sizeof(uint32_t) or sizeof(uint64_t)

[bettio.davide at gmail dot com]

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

            Bug ID: 111933
           Summary: memcpy on Xtensa not optimized when n ==
                    sizeof(uint32_t) or sizeof(uint64_t)
           Product: gcc
           Version: 11.2.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: bettio.davide at gmail dot com
  Target Milestone: ---

This issue is about what I think being a missing optimization on ESP32 Xtensa
GCC compiler. 

I tested the same issue on versions between gcc 8.4.0 and 11.2.0 with Xtensa
ESP32/ESP32-S2/ESP32-S3 GCC. 

I'm writing some functions for unaligned memory access and I've been checking
them with Compiler Explorer (https://godbolt.org/) and I'm getting some (I
think) sub-optimal outputs.

As far as I understood on ESP32 Xtensa a 32-bit unaligned memory access is
faster than 4 8-bit accesses, however I'm getting the following results (using
-O2) and the following snippets of code:

Function that calls the inline from_unaligned_u32:
bool test2(uint32_t *in)
{
    uint32_t got = from_unaligned_u32(in);
    if (got > 5) {
        return true;
    }

    return false;
}

A:
uint32_t from_unaligned_u32(uint32_t *unaligned)
{
    uint32_t tmp;
    tmp = *unaligned;
    return tmp;
}

generates:
test2(unsigned int*):
        entry   sp, 32
        l32i.n  a8, a2, 0
        movi.n  a2, 1
        bgeui   a8, 6, .L2
        movi.n  a2, 0
.L2:
        extui   a2, a2, 0, 1
        retw.n


B:
inline uint32_t from_unaligned_u32(uint32_t *unaligned)
{
    uint32_t tmp;
    memcpy(&tmp, unaligned, sizeof(tmp));
    return tmp;
}

generates:
test2(unsigned int*):
        entry   sp, 48
        l8ui    a8, a2, 2
        l8ui    a10, a2, 0
        l8ui    a9, a2, 1
        l8ui    a2, a2, 3
        s8i     a10, sp, 0
        s8i     a2, sp, 3
        s8i     a9, sp, 1
        s8i     a8, sp, 2
        l32i.n  a8, sp, 0
        movi.n  a2, 1
        bgeui   a8, 6, .L2
        movi.n  a2, 0
.L2:
        extui   a2, a2, 0, 1
        retw.n

My assumption here is that unaligned access on Xtensa ESP32 is faster than
calling memcpy or multiple 1-byte loads (please let me know if I am wrong), so
from my point of view is a missing optimization.

I would expect both A and B generating the same assembly code like on other
archs.

Also interstingly the uint64_t "B" version (that is similar to the previous),
generates a call to memcpy instead of some inline code.

[Bug middle-end/111933] memcpy on Xtensa not optimized when n == sizeof(uint32_t) or sizeof(uint64_t)

[rguenth at gcc dot gnu.org]

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

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
uint32_t from_unaligned_u32(uint32_t *unaligned)
{
    uint32_t tmp;
    tmp = *unaligned;

note this isn't an unaligned access since you dereference a uint32_t pointer

[Bug middle-end/111933] memcpy on Xtensa not optimized when n == sizeof(uint32_t) or sizeof(uint64_t)

[bettio.davide at gmail dot com]

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

--- Comment #2 from Davide Bettio <bettio.davide at gmail dot com> ---
(In reply to Richard Biener from comment #1)
> uint32_t from_unaligned_u32(uint32_t *unaligned)
> {
>     uint32_t tmp;
>     tmp = *unaligned;
> 
> note this isn't an unaligned access since you dereference a uint32_t pointer

Let me explain better my purpose: I was writing a function for reading uint32_t
and uint64_t values at any address, including odd ones such as 0x00002345.

So as far as I know the only generic way to do this is either casting them to
uint8_t and reading them as 4 or 8 bytes, or using memcpy.
My expectation is that memcpy is always replaced with a load instruction when
fast unaligned memory access is available.

Let me know if I am making any wrong assumptiom.