[Bug c/105343] New: Inefficient initialisation in some kinds of structs

[Bug c/105343] New: Inefficient initialisation in some kinds of structs

[david at westcontrol dot com]

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

            Bug ID: 105343
           Summary: Inefficient initialisation in some kinds of structs
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: david at westcontrol dot com
  Target Milestone: ---

struct S { int a[1000]; };
struct X { struct S s; int b[2];};

extern int foobar(struct X * p);

int foo(struct S *s)
{
    struct X x = { *s };
    return foobar(&x);
}


When the size of the array "a" is small enough that the compiler does the
initialisation inline, the code is fine.  With a bigger array it uses memset
and memcpy, either as calls to external functions or inline loops depending on
details of the version of gcc and the target.  (This too is appropriate.)

However, it does that by turning the code into the equivalent of :

    memset(&x, 0, sizeof(struct X));
    memcpy(&x, s, sizeof(struct S));

It /should/ be doing :

    memset(&x.b, 0, sizeof(struct X.b));
    memcpy(&x, s, sizeof(struct S));

In other words, it is first zeroing out the entire X structure, then copying
from *s into the structure.  Only the extra part of X, the array "b", needs to
be zero'ed.

[Bug c/105343] Inefficient initialisation in some kinds of structs

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|normal                      |enhancement

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
There might be a dup or a related bug to this one already. I remember seeing
it.

[Bug middle-end/105343] Inefficient initialisation in some kinds of structs

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2022-04-22
     Ever confirmed|0                           |1
            Version|unknown                     |12.0
          Component|c                           |middle-end

--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
Hmm, on x86-64 I see

  <bb 2> :
  x = {};
  x.s = *s_3(D);
  _6 = foobar (&x);

so I suppose this is DSE mem* trimming not working for the x = {}; variant.
There might be already a bug with respect to that.

Indeed gimplification could be smarter and handle the contiguous zeros case
better.  I also wonder why it chooses to do the zero pre-init for just two
ints, maybe it gives up for arrays.

[Bug middle-end/105343] Inefficient initialisation in some kinds of structs

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
categorize_ctor_elements computes

(gdb) p num_nonzero_elements 
$3 = 1000
(gdb) p num_unique_nonzero_elements
$4 = 1000
(gdb) p num_ctor_elements
$5 = 1000
(gdb) p complete_p
$6 = false

so it fails to compute the required CTOR elements (num_ctor_elements lacks
the missing parts), falling into

        else if (!complete_p)
          /* If the constructor isn't complete, clear the whole object
             beforehand, unless CONSTRUCTOR_NO_CLEARING is set on it.

             ??? This ought not to be needed.  For any element not present
             in the initializer, we should simply set them to zero.  Except
             we'd need to *find* the elements that are not present, and that
             requires trickery to avoid quadratic compile-time behavior in
             large cases or excessive memory use in small cases.  */
          cleared = !CONSTRUCTOR_NO_CLEARING (ctor);