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

["ramana.radhakrishnan at arm dot com" <gcc-bugzilla at gcc dot gnu dot org>]

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

--- Comment #19 from ramana.radhakrishnan at arm dot com <ramana.radhakrishnan at arm dot com> ---
On 06/12/14 08:46, fredrik.hederstierna@securitas-direct.com wrote:
> 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.

It might be another issue or it may well be an issue with LRA not many 
could tell for certain unless we could get a small testcase to look at.

What we'd like is a small testcase that shows the problem compared with 
gcc 4.8.3 to progress this further.

Please file a new bug report following the instructions in 
https://gcc.gnu.org/bugs/#report

in this particular case we'd be interested in all command line options 
that were used.


regards
Ramana


>
> BR /Fredrik
>