On Mon, 27 Nov 2017, Juan Cabrera wrote:
Hello,
I think I found a small optimization issue by mistake while checking
the generated assembly code for a function that was using `memcpy`.
Here's the smallest example showing the issue: https://godbolt.org/g/xTn4bZ
When I put a 1 (instead of sizeof int) on the third parameter of
std::memcpy() the resulting code stores the byte on the stack and then
reads it back before returning from the function, (clang doesn't seem
to have the issue)
int read(const void* buffer)
{
int r;
std::memcpy(&r, buffer, 1);
// std::memcpy(&r, buffer, sizeof(r));
return r;
}
This generates the following code (GCC 7.2):
read(void const*):
movzx eax, BYTE PTR [rdi]
mov BYTE PTR [rsp-4], al
mov eax, DWORD PTR [rsp-4]
ret
While clang 5.0.0 generates the following:
read(void const*):
movzx eax, byte ptr [rdi]
ret
(Both compiled with -O3)
Do you think there's a reason for this or is this just an optimizer bug?
Please file enhancement requests in bugzilla.
MEM[(char * {ref-all})&r] = _4;
_6 = r;
Maybe using BIT_INSERT_EXPR would be a nice intermediate step to help
notice that we can just zero-extend _4?
--
Marc Glisse
