[Bug tree-optimization/98982] New: Optimizing loop variants of fixed-byte-order functions

[jak@jak-linux.org]

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

            Bug ID: 98982
           Summary: Optimizing loop variants of fixed-byte-order functions
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: tree-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: jak@jak-linux.org
  Target Milestone: ---

These functions actually generate loops whereas they should just be optimized
to no-ops.

It's the classic byte-read/write idiom for little endian encoded integers, just
written as a loop, to accomodate varying sizeof(T) in the template.

template <typename T>
struct little_endian
{
   uint8_t data[sizeof(T)];

   constexpr little_endian() : data{}
   {
   }
   constexpr little_endian(T in)
   {
      for (size_t i = 0; i < sizeof(T); i++)
        data[i] = (in >> (8 * i)) & 0xFF;
   }
   constexpr operator T() const
   {
      T res = 0;
      for (size_t i = 0; i < sizeof(T); i++)
        res |= static_cast<T>(data[i]) << (8u * i);
      return res;
   }
};


-O3 or -funroll-loops correctly unrolls the encoding (the constructor), but the
operator T() still ends up being

▸   endbr64
▸   movabsq▸$72057594037927935, %rdx
▸   movq▸   %rdi, %rax
▸   shrq▸   $56, %rax
▸   andq▸   %rdi, %rdx
▸   salq▸   $56, %rax
▸   orq▸%rdx, %rax
▸   ret

Seems weird to me.