[Bug tree-optimization/115354] New: Large -Os code size increase related to -ftree-sra

[Bug tree-optimization/115354] New: Large -Os code size increase related to -ftree-sra

[gus at projectgus dot com]

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

            Bug ID: 115354
           Summary: Large -Os code size increase related to -ftree-sra
           Product: gcc
           Version: 14.1.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: tree-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: gus at projectgus dot com
  Target Milestone: ---

Created attachment 58353
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58353&action=edit
Source file shows code size increase in mp_parse function

After upgrading arm-none-eabi-gcc from 13.2 to 14.1 we noticed some increases
in code size when compiling the MicroPython project with -Os.

Bisecting turned up a commit that introduces a 15% code size increase in an
(admittedly quite complex) function.

The commit is aae723d3 "sra: SRA of non-escaped aggregates passed by reference
to calls".

GCC 13.2 and the parent of commit aae723d3 both produce a 2846 byte text
section when building the attached code.

GCC 14.1, commit aae723d3, and recent master branch all produce a 3282 byte
text section.

Full compiler command line is "arm-none-eabi-gcc -Wall -Wextra -std=c99
-mcpu=cortex-m4 -Os -c"

If -fno-tree-sra argument is added then the text section reverts to 2846 bytes.
Assembler output from commit aae723d3 passing -fno-tree-sra is identical to
output from the parent commit without -fno-tree-sra.

Unfortunately the function is quite complex and includes gotos and calls to
noreturn functions. I haven't been able to isolate a smaller test case but I
thought it was worth reporting anyway, as the size jump is quite noticeable.

Version and configuration details for the local test builds:

> Target: arm-none-eabi
> Configured with: /home/gus/dev/gcc/configure --target=arm-none-eabi --prefix=/home/gus/ry/george/tmp/gcc-temp-aae723d3 --with-sysroot=/home/gus/ry/george/tmp/gcc-temp-aae723d3/arm-none-eabi --enable-languages=c --enable-plugins --disable-decimal-float --disable-libffi --disable-libgomp --disable-libmudflap --disable-libquadmath --disable-libssp --disable-libstdcxx-pch --disable-nls --disable-shared --disable-threads --disable-tls --with-gnu-as --with-gnu-ld --with-system-zlib --with-newlib --with-headers=/home/gus/ry/george/tmp/gcc-temp-aae723d3/arm-none-eabi/include --with-python-dir=share/gcc-arm-none-eabi --with-gmp --with-mpfr --with-mpc --with-isl --with-libelf --enable-gnu-indirect-function --with-host-libstdcxx='-static-libgcc -Wl,-Bstatic,-lstdc++,-Bdynamic -lm' --with-multilib-list=rmprofile
> gcc version 14.0.0 20231124 (experimental) (GCC)

[Bug tree-optimization/115354] [14/15 Regression] Large -Os code size increase related to -ftree-sra

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|Large -Os code size         |[14/15 Regression] Large
                   |increase related to         |-Os code size increase
                   |-ftree-sra                  |related to -ftree-sra
   Target Milestone|---                         |14.2
                 CC|                            |jamborm at gcc dot gnu.org
           Keywords|                            |missed-optimization

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
The optimization is performed optimistically anticipating followup
optimizations to make up for the immediate caused bloat (that's what I
understand).  I'm not
sure if we make any attempt of assessing the possibility of that to happen
but certainly this transform could be disabled when optimizing for size or
for cold calls?

[Bug tree-optimization/115354] [14/15 Regression] Large -Os code size increase related to -ftree-sra since r14-5831-gaae723d360ca26

[gus at projectgus dot com]

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

--- Comment #2 from Angus Gratton <gus at projectgus dot com> ---
Thanks Richard, that's very helpful context (I don't quite have my head around
SRA to be honest!)

For non-LTO MicroPython builds (mostly C, no C++), building with -Os
-fno-tree-sra has almost no impact (for GCC versions before this change), and
undoes the code size increase for GCC versions after this change.

For LTO MicroPython builds, -Os -fno-tree-sra consistently results in a big
code size increase. (And there is also a code size increase when building with
the GCC version after this change vs before.)

I'll experiment with the function and see if I can find what is causing later
optimisations to not shrink the code size back down.

[Bug tree-optimization/115354] [14/15 Regression] Large -Os code size increase related to -ftree-sra since r14-5831-gaae723d360ca26

[gus at projectgus dot com]

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

--- Comment #3 from Angus Gratton <gus at projectgus dot com> ---
Sorry, my notes about LTO builds look like they were wrong.

MicroPython LTO builds with -Os -fno-tree-sra seem to consistently reduce code
size as well, for both the "before" and "after" GCC versions, including undoing
the increase from the "after" version.