[Bug tree-optimization/117057] New: [15 Regression] XFAIL of parts of gcc.dg/strlenopt-32.c, strlenopt doesn't handle MEM[&string + CST] = { 0, a_1 };

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

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

            Bug ID: 117057
           Summary: [15 Regression] XFAIL of parts of
                    gcc.dg/strlenopt-32.c, strlenopt doesn't handle
                    MEM[&string + CST] = { 0, a_1 };
           Product: gcc
           Version: 15.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: tree-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: rguenth at gcc dot gnu.org
  Target Milestone: ---

gcc.dg/strlenopt-32.c has XFAILed the optimization for f9() and f10()
because the strlen pass doesn't handle

  _11 = {0, b_6(D)};
  __builtin_memcpy (&a, "foo.bar", 8);
  MEM <vector(2) char> [(char *)&a + 3B] = _11;
  _9 = strlen (&a);

this vectorization is new and some backends expose v2qi and unaligned
stores of that.  On x86 the assembly for such a store is

        xorl    %eax, %eax
        movb    %dl, %ah
        movw    %ax, 3(%rdi)

compared to

        movb    %dl, 4(%rsp)
        movb    $0, 3(%rsp)

both are same size, the xor can execute in rename stage and one less
store buffer entry is used and a bigger store allows more store-to-load
forwarding, so the vectorizing isn't a clear miss (store merging doesn't
handle this case).