Optimization issue

Marc Glisse marc.glisse@inria.fr
Tue Nov 28 06:24:00 GMT 2017


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



More information about the Gcc-help mailing list