[Bug rtl-optimization/59535] [4.9 regression] -Os code size regressions for Thumb1/Thumb2 with LRA

[fredrik.hederstierna@securitas-direct.com]

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

Fredrik Hederstierna <fredrik.hederstierna@securitas-direct.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |fredrik.hederstierna@securi
                   |                            |tas-direct.com

--- Comment #18 from Fredrik Hederstierna <fredrik.hederstierna@securitas-direct.com> ---
I compared GCC 4.8.3 and GCC 4.9.0 for arm-none-eabi, and I still see a code
size increase for thumb1 (and thumb2) for both my arm966e and my cortex-m4
targets.

GCC 4.8.3
  RAM used     93812 
  Flash used   515968

GCC 4.9.0
  RAM used     93812 (same)
  Flash used   522608 (+1.3%)

Then I tried to disable LRA and results got better:

GCC 4.9.0 : added flag "-mno-lra"
  RAM used     93812 (same)
  Flash used   519624 (+0.7%)

Flags used are otherwise identical for both tests:

  -Os -g3 -ggdb3 -gdwarf-4
  -fvar-tracking-assignments -fverbose-asm -fno-common -ffunction-sections  
-fdata-sections -fno-exceptions -fno-asynchronous-unwind-tables
-fno-unwind-tables
  -mthumb -mcpu=arm966e-s -msoft-float -mno-unaligned-access

Generally GCC 4.9.0 seems to produce larger code, I tried to experiement with
LTO (-flto -flto-fat-objects), but then code size increased even more for both
GCC 4.8.3 and GCC 4.9.0, I was expecting a code decrease though.

Sorry I cannot share exact sources used for compilation here, I can share
toolchain build script though on request, or try to setup a small test case.

I first just wanted to confirm that this bug really is fixed and resolved, so
its not a new bug or another known issue.

BR /Fredrik