[Bug tree-optimization/104665] New: Failure to recognize memcpy

[Bug tree-optimization/104665] New: Failure to recognize memcpy

[monad at posteo dot net]

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

            Bug ID: 104665
           Summary: Failure to recognize memcpy
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: tree-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: monad at posteo dot net
  Target Milestone: ---

The following serialization code:

void serialize_le(std::byte* __restrict dst, const std::uint32_t* __restrict
src)
{
    for (int i = 0; i < 32; ++i, ++src)
    {
        *dst++ = static_cast<std::byte>((*src >>  0) & 0xff);
        *dst++ = static_cast<std::byte>((*src >>  8) & 0xff);
        *dst++ = static_cast<std::byte>((*src >> 16) & 0xff);
        *dst++ = static_cast<std::byte>((*src >> 24) & 0xff);
    }
}

is not recognized as just copying memory.
Both clang and gcc fail to optimize it properly, however gcc creates an
"interesting" mess.
Flags used are `-std=c++17 -O3 -march=haswell`


<https://godbolt.org/z/GM8jqssYd>

[Bug tree-optimization/104665] Failure to recognize memcpy

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Please include the full code here, including the #include directives. Not just
a link to godbolt.org.

[Bug tree-optimization/104665] Failure to recognize memcpy

[monad at posteo dot net]

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

--- Comment #2 from monad at posteo dot net ---
The full code including headers is:

#include <cstddef>
#include <cstdint>
#include <cstring>


void serialize_le(std::byte* __restrict dst, const std::uint32_t* __restrict
src)
{
    for (int i = 0; i < 32; ++i, ++src)
    {
        *dst++ = static_cast<std::byte>((*src >> 24) & 0xff);
        *dst++ = static_cast<std::byte>((*src >> 16) & 0xff);
        *dst++ = static_cast<std::byte>((*src >>  8) & 0xff);
        *dst++ = static_cast<std::byte>((*src >>  0) & 0xff);
    }
}

[Bug tree-optimization/104665] Failure to recognize memcpy

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2022-02-23
           Severity|normal                      |enhancement
     Ever confirmed|0                           |1

--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
A couple of reasons.
First is store merging happens too late.
Second reason is store merging does not work in the loop case.

Take:
#if 1
enum b : unsigned char{};
#else
typedef unsigned char b;
#endif

void serialize_le(b* __restrict dst, const unsigned* __restrict src)
{
   // for (int i = 0; i < 128; ++i, ++src)
    {
        unsigned t = *src;
        *dst++ = static_cast<b>((t >>  0) & 0xff);
        *dst++ = static_cast<b>((t >>  8) & 0xff);
        *dst++ = static_cast<b>((t >> 16) & 0xff);
        *dst++ = static_cast<b>((t >> 24) & 0xff);
    }
}

This gets optimized to one load followed by one store. But once you add the
loop, and use -fno-tree-vectorize (because GCC's vectorizer gets kicked in
which causes other issues), the stores are not merged into one.

Also store merging happens way after loop distrubution happens so ...

[Bug tree-optimization/104665] Failure to recognize memcpy

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> ---
In principle loop distribution could recognize this but it currently is doing
too simplistic checking for this, not sure how difficult handling this would
be.