[Bug tree-optimization/109213] New: [13 Regression] -Os generates significantly more code

[Bug tree-optimization/109213] New: [13 Regression] -Os generates significantly more code

[theodort at inf dot ethz.ch]

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

            Bug ID: 109213
           Summary: [13 Regression] -Os generates significantly more code
           Product: gcc
           Version: 13.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: tree-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: theodort at inf dot ethz.ch
  Target Milestone: ---

Input C-code:

static char g, d[5] = {0};
static int f = 0, *e;
static void b(int) {};

static int i() {
    for (int j =0; j < 1; j +=1)
        f = 0;
    return 0;
}

static void m() {
    int n[10];
    int o[56] = {};
    for (int h = 0; h < 3; h++)
        if (d[h])
            for (; f; f++)
                if (n[0])
                    break;

    int *r[] = {&o[0]};
}


int main() {
    int p[10] = {};
    m();
    if (!i()) {
        int *q = &p[0];
        for (; g;)
            b(e == q);
    }
}

-----------------------------------------------------
12.2 -Os:

main:
        xorl    %eax, %eax
        movl    %eax, f(%rip)
        xorl    %eax, %eax
        ret

-----------------------------------------------------
trunk -Os: 

m:
        movl    f(%rip), %eax
        xorl    %edx, %edx
        xorl    %ecx, %ecx
.L5:
        cmpb    $0, d(%rdx)
        je      .L2
        movl    -40(%rsp), %esi
.L3:
        testl   %eax, %eax
        je      .L2
        testl   %esi, %esi
        jne     .L2
        incl    %eax
        movb    $1, %cl
        jmp     .L3
.L2:
        incq    %rdx
        cmpq    $3, %rdx
        jne     .L5
        testb   %cl, %cl
        je      .L1
        movl    %eax, f(%rip)
.L1:
        ret
main:
        xorl    %eax, %eax
        call    m
        xorl    %eax, %eax
        movl    %eax, f(%rip)
        xorl    %eax, %eax
        ret
d:
        .zero   5

[Bug tree-optimization/109213] [13 Regression] -Os generates significantly more code

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |13.0
           Keywords|                            |missed-optimization,
                   |                            |needs-bisection

[Bug tree-optimization/109213] [13 Regression] -Os generates significantly more code

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
The difference is due to inlining of m into main.
The reason for the difference of inlining is due to removal of:
    p = {};
statement from main in dse which changes the overall cost of the TU ...

[Bug tree-optimization/109213] [13 Regression] -Os generates significantly more code

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Basically just unluckness ...

[Bug tree-optimization/109213] [13 Regression] -Os generates significantly more code

[pinskia at gcc dot gnu.org]

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

--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
In fact if you change main to:
int main() {
    int p[10];
    m();
    if (!i()) {
        int *q = &p[0];
        for (; g;)
            b(e == q);
    }
}

GCC 12 also does not do the inlining.

[Bug tree-optimization/109213] [13 Regression] -Os generates significantly more code

[pinskia at gcc dot gnu.org]

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

--- Comment #4 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
If you force m to be always_inline, we are back to GCC 12 code generation.

I don't think there is anything GCC can do with differently; the heurstics are
not tuned for these small "benchmark" functions either.

[Bug tree-optimization/109213] [13 Regression] -Os generates significantly more code since r13-723

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2023-03-21
                 CC|                            |jakub at gcc dot gnu.org
     Ever confirmed|0                           |1
           Keywords|needs-bisection             |
            Summary|[13 Regression] -Os         |[13 Regression] -Os
                   |generates significantly     |generates significantly
                   |more code                   |more code since r13-723

--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
This changed with r13-723-g1adf11822bd48f4d65156b7642514630c08c4d00

[Bug tree-optimization/109213] [13 Regression] -Os generates significantly more code since r13-723

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |hubicka at gcc dot gnu.org

--- Comment #6 from Richard Biener <rguenth at gcc dot gnu.org> ---
t.c:26:5: missed:   not inlinable: main/7 -> m/6, --param
large-stack-frame-growth limit reached

and after the DSE:

IPA function summary for main/7 inlinable
  global time:     38.636364
  self size:       11
  global size:     11
  min size:       8
  self stack:      0
  global stack:    0

IPA function summary for m/6 inlinable
  global time:     86.705545
  self size:       22
  global size:     22
  min size:       19
  self stack:      264
  global stack:    264

vs.

IPA function summary for main/7 inlinable
  global time:     42.636364
  self size:       14
  global size:     14
  min size:       11
  self stack:      40
  global stack:    40

without the DSE.  And we apply the limit in a quite complicated way
in caller_growth_limits, changing mains stack size to 1 or 4 doesn't
help, so it isn't a totally arbitrary special-casing of zero caller stack
size.

I'm leaning towards a WONTFIX or reclassify as non-regression.  The bug
is definitely not that we now do more DSE, the pre-existing bug might be
that we take the absolute size of the caller stack into account.

[Bug tree-optimization/109213] [13 Regression] -Os generates significantly more code since r13-723

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P2

--- Comment #7 from Richard Biener <rguenth at gcc dot gnu.org> ---
So the gist is that IMHO inlining shouldn't regress when 40 <- 264 is
changed to 0 <- 264 since the overall stack size is smaller and the absolute
growth is the same.  That's just counter-intuitive.

This behavior isn't a recent regression, but the testcase regressed in 13
because of the extra variable elimination.  For this reason making P2,
a regression when that stack limit related behavior was introduced.

Honza?

[Bug tree-optimization/109213] [13 Regression] -Os generates significantly more code since r13-723

[hubicka at gcc dot gnu.org]

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

--- Comment #8 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
We have large-stack-frame-growth that is relative, so yes, increasing stack
size of caller makes gcc to think that it is heavy and making it event heavier
will not hurt that much.

We originally ran into stack size growth issues after implementing logic to
inline functions called once. In things like glibc printf where we ended up
inlining some exotic formater (as called once) that made the stack too large
for multithreaded apps.  Also sometimes we inlined some heavy function that is
off the hot path. While relative growth cap may not be best possible for all
cases, I can't think of reasonable way doing this better.

With the new code to determine basic blocks that are executed at every
execution of the function I plan to relax stack size limits a bit by bypassing
them when the call is known to be always allocated (and thus the stack will be
always taken)

This is also relatively common problem in Fortran where fortran IO (typically
done somewhere in debug code) tends to crate large on-stack structures
preventing inlining.

[Bug tree-optimization/109213] [13/14 Regression] -Os generates significantly more code since r13-723

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|13.0                        |13.2

--- Comment #9 from Richard Biener <rguenth at gcc dot gnu.org> ---
GCC 13.1 is being released, retargeting bugs to GCC 13.2.

[Bug tree-optimization/109213] [13/14 Regression] -Os generates significantly more code since r13-723

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|13.2                        |13.3

--- Comment #10 from Richard Biener <rguenth at gcc dot gnu.org> ---
GCC 13.2 is being released, retargeting bugs to GCC 13.3.