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.
