[Bug tree-optimization/108953] inefficient codegen for trivial equality

[jakub at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
BTW, I've tried:
struct A
{
  unsigned char a, b, c, d;
  unsigned short e, f;
  int g;
  bool operator== (A const &) const = default;
};

struct B
{
  unsigned char b;
  bool operator== (B const &) const = default;
};

struct C
{
  unsigned char a, b, c;
  B d;
  unsigned short e, f;
  int g;
  bool operator== (C const &) const = default;
};

struct D
{
  unsigned char b;
  bool operator== (D const &x) const { return b == x.b; }
};

struct E
{
  unsigned char a, b, c;
  D d;
  unsigned short e, f;
  int g;
  bool operator== (E const &) const = default;
};

struct F
{
  unsigned char a, b, c, d;
  unsigned short e, f;
  int g;
  bool operator== (F const &x) const {
    if (a != x.a) return false;
    if (b != x.b) return false;
    if (c != x.c) return false;
    if (d != x.d) return false;
    if (e != x.e) return false;
    if (f != x.f) return false;
    return g == x.a;
  }
};

struct G
{
  unsigned char a, b, c, d;
  unsigned short e, f;
  float g;
  bool operator== (G const &) const = default;
};

bool
foo (A const &lhs, A const &rhs)
{
  return lhs == rhs;
}

bool
bar (C const &lhs, C const &rhs)
{
  return lhs == rhs;
}

bool
baz (E const &lhs, E const &rhs)
{
  return lhs == rhs;
}

bool
qux (F const &lhs, F const &rhs)
{
  return lhs == rhs;
}

bool
corge (G const &lhs, G const &rhs)
{
  return lhs == rhs;
}

to see what clang trunk does and they optimize this way only the defaulted
bool A::operator== (A const &) const, nothing else, so it clearly isn't a late
pattern matching.  Probably just they notice that the structure only contains
integral fields
and in that case emit memcmp for the portions without padding bits if certain
conditions are met (seems two consecutive char fields are vectorized, but 3
result in memcmp).
But certainly even the nested struct with also defaulted operator== isn't
optimized that way at all, even the unaffected consecutive parts there.
Just in case we'd like to do this as a late pattern matching optimization and
in the C++ FE.

Note, I wonder if reassoc wouldn't be the right spot instead of store-merging.