[Bug tree-optimization/107263] New: Memcpy not elided when initializing struct

[Bug tree-optimization/107263] New: Memcpy not elided when initializing struct

[jmuizelaar at mozilla dot com]

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

            Bug ID: 107263
           Summary: Memcpy not elided when initializing struct
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: tree-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: jmuizelaar at mozilla dot com
  Target Milestone: ---

With the following code

struct Foo {
    Foo* next;
    char arr[580];
};

void ctx_push(Foo* f) {
    Foo tmp = { f->next };
    *f = tmp;
}

Clang is able to generate code that just memsets `arr`. GCC instead initializes
the entire struct on the stack and then copies it into `f`.

https://gcc.godbolt.org/z/Yzcbs4G71

[Bug tree-optimization/107263] Memcpy not elided when initializing struct

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|normal                      |enhancement
           Keywords|                            |missed-optimization

[Bug tree-optimization/107263] Memcpy not elided when initializing struct

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2022-10-17
            Version|unknown                     |13.0
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |NEW
                 CC|                            |jamborm at gcc dot gnu.org

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
Confirmed.  The frontend leaves us with

  <<cleanup_point   struct Foo tmp = {};>>;
  <<cleanup_point <<< Unknown tree: expr_stmt
    tmp.next = f->next >>>>>;
  <<cleanup_point <<< Unknown tree: expr_stmt
    (void) (*NON_LVALUE_EXPR <f> = *(const struct Foo &) &tmp) >>>>>;

and ESRA sees

  <bb 2> :
  tmp = {};
  _1 = f_4(D)->next;
  tmp.next = _1;
  *f_4(D) = tmp;
  tmp ={v} {CLOBBER(eol)};
  return;

ESRA somewhat senselessly does

  <bb 2> :
  tmp = {};
  tmp$next_8 = 0B;
  _1 = f_4(D)->next;
  tmp$next_9 = _1;
  tmp.next = tmp$next_9;
  *f_4(D) = tmp;
  tmp ={v} {CLOBBER(eol)};
  return;

it doesn't scalarize the array because that's too large.  I would guess
that Clang doesn't split the initializer and thus its aggregate copy
propagation somehow manages to elide 'tmp'.  We don't have a good
place to peform the desired optimization, certainly the split
initialization of 'tmp' complicates things.

In principle it would be SRAs job since I think it does most of the
necessary analysis, it just lacks knowledge on how to re-materialize
*f_4(D) efficiently at the point of the aggregate assignment?
It has

Candidate (2384): tmp
Too big to totally scalarize: tmp (UID: 2384)
Created a replacement for tmp offset: 0, size: 64: tmp$nextD.2425

Access trees for tmp (UID: 2384):
access { base = (2384)'tmp', offset = 0, size = 4736, expr = tmp, type = struct
Foo, reverse = 0, grp_read = 1, grp_write = 1, grp_assignment_read = 1,
grp_assignment_write = 1, grp_scalar_read = 0, grp_scalar_write = 0,
grp_total_scalarization = 0, grp_hint = 0, grp_covered = 0,
grp_unscalarizable_region = 0, grp_unscalarized_data = 1, grp_same_access_path
= 1, grp_partial_lhs = 0, grp_to_be_replaced = 0, grp_to_be_debug_replaced = 0}
* access { base = (2384)'tmp', offset = 0, size = 64, expr = tmp.next, type =
struct Foo *, reverse = 0, grp_read = 1, grp_write = 1, grp_assignment_read =
1, grp_assignment_write = 1, grp_scalar_read = 0, grp_scalar_write = 1,
grp_total_scalarization = 0, grp_hint = 0, grp_covered = 1,
grp_unscalarizable_region = 0, grp_unscalarized_data = 0, grp_same_access_path
= 1, grp_partial_lhs = 0, grp_to_be_replaced = 1, grp_to_be_debug_replaced = 0}

but it fails to record that for the size 4736 write there's a clear performed
that's cheaply to re-materialize (and no variables need to be created).  SRA
could probably track writes from only constants that way, avoiding to create
scalar replacements.

[Bug tree-optimization/107263] Memcpy not elided when initializing struct

[jmuizelaar at mozilla dot com]

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

--- Comment #2 from Jeff Muizelaar <jmuizelaar at mozilla dot com> ---
Even for small arrays clang does a noticeably better job:
https://gcc.godbolt.org/z/4d3TjGazY

[Bug tree-optimization/107263] Memcpy not elided when initializing struct

[hiraditya at msn dot com]

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

AK <hiraditya at msn dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |hiraditya at msn dot com

--- Comment #3 from AK <hiraditya at msn dot com> ---
Seems like a duplicate of #59863 ?