[Bug c/61578] New: Code size increase for ARM thumb compared to 4.8.x when compiling with -Os

[Bug c/61578] New: Code size increase for ARM thumb compared to 4.8.x when compiling with -Os

[fredrik.hederstierna@securitas-direct.com]

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

            Bug ID: 61578
           Summary: Code size increase for ARM thumb compared to 4.8.x
                    when compiling with -Os
           Product: gcc
           Version: 4.9.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: fredrik.hederstierna@securitas-direct.com

We have problems when trying to switch from GCC 4.8.3 to GCC 4.9.0 (arm-eabi
thumb1 for arm966e-s core) due to significant code size increase (1-2%).

I attach our toolchain build scripts and two small example programs, though I'm
not fully convinced that these examples fully catch the issue.
Although the examples show increase +4.81% and +2% growth, though the examples
are slightly constructed.

First I suspected it was related to Bug 59535, since the code size decrease
significantly when compiling without LRA (-mno-lra), though still it does not
make the full picture, since still the codes size is ~1% bigger then GCC 4.8.3.

We also tried with and without LTO, but it does not solve our problem either.
See attached example.
Build with 'make' and compare with 'make compare'.

Thanks and Best Regards,
/Fredrik

[Bug c/61578] Code size increase for ARM thumb compared to 4.8.x when compiling with -Os

[fredrik.hederstierna@securitas-direct.com]

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

--- Comment #1 from Fredrik Hederstierna <fredrik.hederstierna@securitas-direct.com> ---
Created attachment 32980
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=32980&action=edit
Toolchain build script.

[Bug c/61578] Code size increase for ARM thumb compared to 4.8.x when compiling with -Os

[fredrik.hederstierna@securitas-direct.com]

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

--- Comment #2 from Fredrik Hederstierna <fredrik.hederstierna@securitas-direct.com> ---
Created attachment 32981
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=32981&action=edit
Toolchain build script 4.9.0

[Bug c/61578] Code size increase for ARM thumb compared to 4.8.x when compiling with -Os

[fredrik.hederstierna@securitas-direct.com]

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

--- Comment #3 from Fredrik Hederstierna <fredrik.hederstierna@securitas-direct.com> ---
Created attachment 32982
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=32982&action=edit
Makefile for examples.

[Bug c/61578] Code size increase for ARM thumb compared to 4.8.x when compiling with -Os

[fredrik.hederstierna@securitas-direct.com]

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

--- Comment #4 from Fredrik Hederstierna <fredrik.hederstierna@securitas-direct.com> ---
Created attachment 32983
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=32983&action=edit
Example source 1.

[Bug c/61578] Code size increase for ARM thumb compared to 4.8.x when compiling with -Os

[fredrik.hederstierna@securitas-direct.com]

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

--- Comment #5 from Fredrik Hederstierna <fredrik.hederstierna@securitas-direct.com> ---
Created attachment 32984
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=32984&action=edit
Example source 2.

[Bug target/61578] Code size increase for ARM thumb compared to 4.8.x when compiling with -Os

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan <ramana at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ramana at gcc dot gnu.org,
                   |                            |vmakarov at gcc dot gnu.org

--- Comment #6 from Ramana Radhakrishnan <ramana at gcc dot gnu.org> ---
We need preprocessed source for someone to actually try this. CC'ing Vlad as
LRA maintainer / author.

[Bug target/61578] Code size increase for ARM thumb compared to 4.8.x when compiling with -Os

[vmakarov at gcc dot gnu.org]

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

--- Comment #7 from Vladimir Makarov <vmakarov at gcc dot gnu.org> ---
(In reply to Ramana Radhakrishnan from comment #6)
> We need preprocessed source for someone to actually try this. CC'ing Vlad as
> LRA maintainer / author.

Thanks for reporting this.  Sorry, I am busy with other things right now.  I'll
start to work on the PR in September.

[Bug target/61578] Code size increase for ARM thumb compared to 4.8.x when compiling with -Os

[fredrik.hederstierna@securitas-direct.com]

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

--- Comment #8 from Fredrik Hederstierna <fredrik.hederstierna@securitas-direct.com> ---
Created attachment 33544
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33544&action=edit
CSiBE test results size

Attached some tests with CSiBE v2.1.1 for arm-eabi.
It seems like the results are very scattered,
sometimes GCC 4.8.3 produces smaller code than GCC 4.9.1,
but on other files it seems to be vice versa.
/Fredrik

[Bug target/61578] Code size increase for ARM thumb compared to 4.8.x when compiling with -Os

[fredrik.hederstierna@securitas-direct.com]

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

--- Comment #9 from Fredrik Hederstierna <fredrik.hederstierna@securitas-direct.com> ---
Created attachment 33866
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33866&action=edit
Simple patch to exclude use of ip

Simple patch that make it possible to optionally exclude use of ip for thumb1
when optimizing for size.

[Bug target/61578] Code size increase for ARM thumb compared to 4.8.x when compiling with -Os

[fredrik.hederstierna@securitas-direct.com]

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

--- Comment #10 from Fredrik Hederstierna <fredrik.hederstierna@securitas-direct.com> ---
Created attachment 33867
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33867&action=edit
Size benchmark gcc 4.8, gcc 4.9 and trunk.

Added updated CSiBE benchmark for GCC 4.8, GCC 4.9 and trunk.
It's obvious that excluding ip gives shorted code.
Then there is something on trunk that makes some project become very large,
which should be investigated perhaps.

[Bug target/61578] Code size increase for ARM thumb compared to 4.8.x when compiling with -Os

[zhenqiang.chen at arm dot com]

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

--- Comment #11 from Zhenqiang Chen <zhenqiang.chen at arm dot com> ---
> Added updated CSiBE benchmark for GCC 4.8, GCC 4.9 and trunk.
> It's obvious that excluding ip gives shorted code.
> Then there is something on trunk that makes some project become very large,
> which should be investigated perhaps.

When compiling CSiBE with trunk, please add option "-std=gnu89".

[Bug target/61578] Code size increase for ARM thumb compared to 4.8.x when compiling with -Os

[ramana at gcc dot gnu.org]

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

--- Comment #12 from Ramana Radhakrishnan <ramana at gcc dot gnu.org> ---
(In reply to Fredrik Hederstierna from comment #9)
> Created attachment 33866 [details]
> Simple patch to exclude use of ip
> 
> Simple patch that make it possible to optionally exclude use of ip for
> thumb1 when optimizing for size.


Please follow https://gcc.gnu.org/contribute.html with respect to contributing
patches.

[Bug target/61578] [4.9/ 5 regression] Code size increase for ARM thumb compared to 4.8.x when compiling with -Os

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan <ramana at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2015-01-15
            Summary|Code size increase for ARM  |[4.9/ 5 regression] Code
                   |thumb compared to 4.8.x     |size increase for ARM thumb
                   |when compiling with -Os     |compared to 4.8.x when
                   |                            |compiling with -Os
     Ever confirmed|0                           |1

--- Comment #13 from Ramana Radhakrishnan <ramana at gcc dot gnu.org> ---
Confirmed.

[Bug target/61578] [4.9/5 regression] Code size increase for ARM thumb compared to 4.8.x when compiling with -Os

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |4.9.3
            Summary|[4.9/ 5 regression] Code    |[4.9/5 regression] Code
                   |size increase for ARM thumb |size increase for ARM thumb
                   |compared to 4.8.x when      |compared to 4.8.x when
                   |compiling with -Os          |compiling with -Os

[Bug target/61578] [4.9/5 regression] Code size increase for ARM thumb compared to 4.8.x when compiling with -Os

[fredrik.hederstierna@securitas-direct.com]

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

--- Comment #14 from Fredrik Hederstierna <fredrik.hederstierna@securitas-direct.com> ---
Created attachment 34916
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34916&action=edit
CSiBE benchmark with gnu89, updates with newer trunk as reference.

I added attachment with new CSiBE measurement from newer trunk,
and now using -std=gnu89 for correctness.

It looks alot better on current trunk, the code size is now smaller than 4.8.x,
so in this case this issue seems at least partly resolved.

Though, still the proposed patch with "-mip-fixed" on trunk,
still gets approx  -0.2%  reduced code size in average,
which might seem significant. See attached docs.

The CSiBE test also it indicates that LRA might improved specific areas,
where the code size gets worse with IP fixed, which could be investigated
further. Example file are libmspack/test/cabd_md5.c.

So, I'm just wondering if you that are or have been involved with this issue,
thinks the proposed patch is a good idea and worth putting time to make it
proper for commit? I just do not want to put time and effort in this patch if
its not likely to get in, or you think its a bad idea.

Please comment :)  Thanks and Kind Regards Fredrik

[Bug target/61578] [4.9/5 regression] Code size increase for ARM thumb compared to 4.8.x when compiling with -Os

[law at redhat dot com]

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

Jeffrey A. Law <law at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P2
                 CC|                            |law at redhat dot com

[Bug target/61578] [4.9 regression] Code size increase for ARM thumb compared to 4.8.x when compiling with -Os

[jakub at gcc dot gnu.org]

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

--- Comment #16 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
GCC 4.9.3 has been released.

[Bug target/61578] [4.9 regression] Code size increase for ARM thumb compared to 4.8.x when compiling with -Os

[jakub at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.9.3                       |4.9.4

[Bug target/61578] [4.9 regression] Code size increase for ARM thumb compared to 4.8.x when compiling with -Os

[fredrik.hederstierna@securitas-direct.com]

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

--- Comment #17 from Fredrik Hederstierna <fredrik.hederstierna@securitas-direct.com> ---
Created attachment 36201
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36201&action=edit
Simple example giving +50% code size increase compared gcc-4.8.5 and gcc-5.2.0

Simple example giving +50% code size increase compared gcc-4.8.5 and gcc-5.2.0.

We still cannot use GCC 4.9, GCC 5.1 and GCC 5.2 due to code size increase.
The GCC 4.8.x produces the smallest binaries for us, and we still haven't
figured out exactly why.

Attached is an attempt to create a test case where GCC 4.9 and after creates
bad code. Please check it out.

With GCC-5.2.0 we got 55% code size increase compared to GCC-4.8.5.

In parallel I work with the CSiBE benchmark and I hope I can contribute with
some more metrics soon.

Thanks and Best Regards/Fredrik

[Bug target/61578] [4.9 regression] Code size increase for ARM thumb compared to 4.8.x when compiling with -Os

[fredrik.hederstierna@securitas-direct.com]

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

--- Comment #18 from Fredrik Hederstierna <fredrik.hederstierna@securitas-direct.com> ---
Created attachment 36202
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36202&action=edit
Disasm for -mthumb also, code size increase was +48%.

[Bug target/61578] [4.9 regression] Code size increase for ARM thumb compared to 4.8.x when compiling with -Os

[fredrik.hederstierna@securitas-direct.com]

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

--- Comment #19 from Fredrik Hederstierna <fredrik.hederstierna@securitas-direct.com> ---
I'm not sure why bug 59535 was closed, same problem might still exist, quote:

> Zhenqiang Chen 2014-09-03 06:17:44 UTC
> 
> Here is a small case to show lra introduces one more register copy (tested with trunk and 4.9).

int isascii (int c)
{
  return c >= 0 && c < 128;
}
With options: -Os -mthumb -mcpu=cortex-m0, I got

isascii:
        mov     r3, #0
        mov     r2, #127
        mov     r1, r3   //???
        cmp     r2, r0
        adc     r1, r1, r3
        mov     r0, r1
        bx      lr

With options: -Os -mthumb -mcpu=cortex-m0 -mno-lra, I got

isascii:
        mov     r2, #127
        mov     r3, #0
        cmp     r2, r0
        adc     r3, r3, r3
        mov     r0, r3
        bx      lr

Testing 4.8.5 and 5.2.0 still still produces same bigger code in GCC 5.2.
So something adds a register copy in this small case.
/Fredrik

[Bug target/61578] [4.9 regression] Code size increase for ARM thumb compared to 4.8.x when compiling with -Os

[vmakarov at gcc dot gnu.org]

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

--- Comment #20 from Vladimir Makarov <vmakarov at gcc dot gnu.org> ---
(In reply to Fredrik Hederstierna from comment #19)
> I'm not sure why bug 59535 was closed, same problem might still exist, quote:
> 
> > Zhenqiang Chen 2014-09-03 06:17:44 UTC
> > 
> > Here is a small case to show lra introduces one more register copy (tested with trunk and 4.9).
> 
> int isascii (int c)
> {
>   return c >= 0 && c < 128;
> }
> With options: -Os -mthumb -mcpu=cortex-m0, I got
> 
> isascii:
> 	mov	r3, #0
> 	mov	r2, #127
> 	mov	r1, r3   //???
> 	cmp	r2, r0
> 	adc	r1, r1, r3
> 	mov	r0, r1
> 	bx	lr
> 
> With options: -Os -mthumb -mcpu=cortex-m0 -mno-lra, I got
> 
> isascii:
> 	mov	r2, #127
> 	mov	r3, #0
> 	cmp	r2, r0
> 	adc	r3, r3, r3
> 	mov	r0, r3
> 	bx	lr
> 
> Testing 4.8.5 and 5.2.0 still still produces same bigger code in GCC 5.2.
> So something adds a register copy in this small case.

Thanks for providing a small test case.  I've started to work on the PR.  I
hope to provide a fix for the case today.
>From gcc-bugs-return-496077-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Sep 01 14:11:53 2015
Return-Path: <gcc-bugs-return-496077-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 114496 invoked by alias); 1 Sep 2015 14:11:52 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 114151 invoked by uid 48); 1 Sep 2015 14:11:48 -0000
From: "kargl at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug fortran/67422] memcpy incorrectly used to copy (potentially) overlapping assumed-size arrays
Date: Tue, 01 Sep 2015 14:11:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: fortran
X-Bugzilla-Version: 5.2.1
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: kargl at gcc dot gnu.org
X-Bugzilla-Status: RESOLVED
X-Bugzilla-Resolution: FIXED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: cc resolution
Message-ID: <bug-67422-4-qnvCrQ8cYE@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-67422-4@http.gcc.gnu.org/bugzilla/>
References: <bug-67422-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2015-09/txt/msg00055.txt.bz2
Content-length: 1472

https://gcc.gnu.org/bugzilla/show_bug.cgi?idg422

kargl at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |kargl at gcc dot gnu.org
         Resolution|INVALID                     |FIXED

--- Comment #3 from kargl at gcc dot gnu.org ---
(In reply to Boris Carlsson from comment #0)
> The assembler code implementation for
>
> subroutine move_buggy(a, b, n)
>     integer :: n, i
>     integer, dimension(*) :: a, b
>     do i = 1, n
>         a(i) = b(i)
>     end do
> end subroutine move_buggy
>
> generated with
>
> gfortran -S move_buggy.f90 -O3
>
> or more "condensed" with
>
> gfortran -S move_buggy.f90 -O1 -ftree-loop-distribute-patterns
> -foptimize-sibling-calls -fstrict-overflow
>
> will replace the loop with a call to memcpy. memcpy is not guaranteed to
> work if the memory locations for a and b overlap, which could be the case
> here. Thus, the above code will not execute as expected (depending on the
> implementation of memcpy) when these optimizations are used. Thus, memcpy
> should not be used here.
>
> The bug is present in gfortran 5.2.1 and 4.9.3 (details below) but NOT in
> 4.7.2.
>

The memory locations for a and b cannot overlap in standard conforming
code.  This restriction goes back to at least Fortran 77, and it is a
restriction on the programmer not the compiler.

[Bug target/61578] [4.9 regression] Code size increase for ARM thumb compared to 4.8.x when compiling with -Os

[fredrik.hederstierna@securitas-direct.com]

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

--- Comment #21 from Fredrik Hederstierna <fredrik.hederstierna@securitas-direct.com> ---
Great, thanks!

Just a note as you are looking into this,
neither GCC 4.8.x nor GCC 5.2.x produces the optimal code I think for this
case,
isn't it better to load result register r0, instead of go over r3?

GCC 4.8.5 (good version):

isascii:
        mov     r2, #127
        mov     r3, #0
        cmp     r2, r0
        adc     r3, r3, r3
        mov     r0, r3
        bx      lr

better ??:

isascii:
        mov     r2, #127
        mov     r3, #0
        cmp     r2, r0
+       adc     r0, r3, r3   <----- put result in R0 directly?
-       adc     r3, r3, r3
-       mov     r0, r3
        bx      lr

This would save one more instruction if I'm thinking right.
BR, Fredrik

[Bug target/61578] [4.9 regression] Code size increase for ARM thumb compared to 4.8.x when compiling with -Os

[vmakarov at gcc dot gnu.org]

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

--- Comment #22 from Vladimir Makarov <vmakarov at gcc dot gnu.org> ---
Author: vmakarov
Date: Tue Sep  1 19:37:52 2015
New Revision: 227382

URL: https://gcc.gnu.org/viewcvs?rev=227382&root=gcc&view=rev
Log:
2015-09-01  Vladimir Makarov  <vmakarov@redhat.com>

        PR target/61578
        * lra-lives.c (process_bb_lives): Process move pseudos with the
        same value for copies and preferences
        * lra-constraints.c (match_reload): Create match reload pseudo
        with the same value from single dying input pseudo.


Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/lra-constraints.c
    trunk/gcc/lra-lives.c

[Bug target/61578] [4.9 regression] Code size increase for ARM thumb compared to 4.8.x when compiling with -Os

[fredrik.hederstierna@securitas-direct.com]

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

--- Comment #23 from Fredrik Hederstierna <fredrik.hederstierna@securitas-direct.com> ---
Thanks for your patch, I tried it out, and it solves the small example fine,
the code now is similar to GCC 4.8 for this particular example.

Though when I ran the full CSiBE benchmark, the code size unfortunately grew
approx +150 bytes overall for the full suite. So the patch did not solve the
generic root problem with code size increase unfortunately.

This is strange and I'm thinking of how to continue from here, this issue has
diverged a bit too much (mostly because of my own fault) with several examples
etc. Do you think we should create separate issues for different small examples
that compiles bad perhaps? but on the same time we need to keep track on the
'generic' overall code size issue as eg. CSiBE points out.

Here's is another small example I tested yesterday that also gives unnecessary
moves, both for arm7tdmi, arm966e-s and cortex-m0 tested.

extern void func(int data);
char cdata[4];
void test(void) {
  int *idata = (int*)cdata;
  func(*idata);
}

Compiles with GCC 4.8.5 (cortex-m0):

00000000 <test>:
   0:   b508            push    {r3, lr}
   2:   4b07            ldr     r3, [pc, #28]   ; (20 <test+0x20>)
   4:   7858            ldrb    r0, [r3, #1]
   6:   781a            ldrb    r2, [r3, #0]
   8:   0200            lsls    r0, r0, #8
   a:   4310            orrs    r0, r2
   c:   789a            ldrb    r2, [r3, #2]
   e:   78db            ldrb    r3, [r3, #3]
  10:   0412            lsls    r2, r2, #16
  12:   4310            orrs    r0, r2
  14:   061b            lsls    r3, r3, #24
  16:   4318            orrs    r0, r3
  18:   f7ff fffe       bl      0 <func>
  1c:   bd08            pop     {r3, pc}
  1e:   46c0            nop                     ; (mov r8, r8)
  20:   00000000        .word   0x00000000

With GCC 6 master with latest LRA patch (+4 bytes):

00000000 <test>:
   0:   b510            push    {r4, lr}
   2:   4c08            ldr     r4, [pc, #32]   ; (24 <test+0x24>)
   4:   7863            ldrb    r3, [r4, #1]
   6:   7821            ldrb    r1, [r4, #0]
   8:   78a0            ldrb    r0, [r4, #2]
   a:   021b            lsls    r3, r3, #8
   c:   430b            orrs    r3, r1
   e:   0400            lsls    r0, r0, #16
  10:   001a            movs    r2, r3   ??? MOVE
  12:   0003            movs    r3, r0   ??? MOVE
  14:   78e0            ldrb    r0, [r4, #3]
  16:   4313            orrs    r3, r2
  18:   0600            lsls    r0, r0, #24
  1a:   4318            orrs    r0, r3
  1c:   f7ff fffe       bl      0 <func>
  20:   bd10            pop     {r4, pc}
  22:   46c0            nop                     ; (mov r8, r8)
  24:   00000000        .word   0x00000000

Kind Regards, Fredrik

[Bug target/61578] [4.9 regression] Code size increase for ARM thumb compared to 4.8.x when compiling with -Os

[vmakarov at gcc dot gnu.org]

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

--- Comment #24 from Vladimir Makarov <vmakarov at gcc dot gnu.org> ---
(In reply to Fredrik Hederstierna from comment #23)
> Thanks for your patch, I tried it out, and it solves the small example fine,
> the code now is similar to GCC 4.8 for this particular example.
> 
> Though when I ran the full CSiBE benchmark, the code size unfortunately grew
> approx +150 bytes overall for the full suite. So the patch did not solve the
> generic root problem with code size increase unfortunately.
> 
> This is strange and I'm thinking of how to continue from here, this issue
> has diverged a bit too much (mostly because of my own fault) with several
> examples etc. Do you think we should create separate issues for different
> small examples that compiles bad perhaps? but on the same time we need to
> keep track on the 'generic' overall code size issue as eg. CSiBE points out.
> 

Either way will work for me.  The most important is to have test cases
somewhere in Bigzilla on which I could work.

I did not expect that the patch solves CSiBE code size degradation.  Therefore
I wrote "a patch for" instead of "patch solving the problem".

I expect it will be a long work to solve the problem.

> Here's is another small example I tested yesterday that also gives
> unnecessary moves, both for arm7tdmi, arm966e-s and cortex-m0 tested.
> 

Thanks.  I'll will investigate it.

[Bug target/61578] [4.9 regression] Code size increase for ARM thumb compared to 4.8.x when compiling with -Os

[fredrik.hederstierna@securitas-direct.com]

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

--- Comment #25 from Fredrik Hederstierna <fredrik.hederstierna@securitas-direct.com> ---
I've but this last example in a separate issue:
Bug 67507 - Code size increase with -Os from GCC 4.8.x to GCC 4.9.x for ARM
thumb1.
I've also previously put this one that causes size increase
Bug 67213 - When compiling for size with -Os loops can get bigger after
peeling.
Best Regards, Fredrik

[Bug target/61578] [4.9 regression] Code size increase for ARM thumb compared to 4.8.x when compiling with -Os

[vmakarov at gcc dot gnu.org]

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

--- Comment #26 from Vladimir Makarov <vmakarov at gcc dot gnu.org> ---
(In reply to Fredrik Hederstierna from comment #23)
> 
> Here's is another small example I tested yesterday that also gives
> unnecessary moves, both for arm7tdmi, arm966e-s and cortex-m0 tested.
> 
> extern void func(int data);
> char cdata[4];
> void test(void) {
>   int *idata = (int*)cdata;
>   func(*idata);
> }
> 
> Compiles with GCC 4.8.5 (cortex-m0):
> 
> 00000000 <test>:
>    0:   b508            push    {r3, lr}
>    2:   4b07            ldr     r3, [pc, #28]   ; (20 <test+0x20>)
>    4:   7858            ldrb    r0, [r3, #1]
>    6:   781a            ldrb    r2, [r3, #0]
>    8:   0200            lsls    r0, r0, #8
>    a:   4310            orrs    r0, r2
>    c:   789a            ldrb    r2, [r3, #2]
>    e:   78db            ldrb    r3, [r3, #3]
>   10:   0412            lsls    r2, r2, #16
>   12:   4310            orrs    r0, r2
>   14:   061b            lsls    r3, r3, #24
>   16:   4318            orrs    r0, r3
>   18:   f7ff fffe       bl      0 <func>
>   1c:   bd08            pop     {r3, pc}
>   1e:   46c0            nop                     ; (mov r8, r8)
>   20:   00000000        .word   0x00000000
> 
> With GCC 6 master with latest LRA patch (+4 bytes):
> 
> 00000000 <test>:
>    0:   b510            push    {r4, lr}
>    2:   4c08            ldr     r4, [pc, #32]   ; (24 <test+0x24>)
>    4:   7863            ldrb    r3, [r4, #1]
>    6:   7821            ldrb    r1, [r4, #0]
>    8:   78a0            ldrb    r0, [r4, #2]
>    a:   021b            lsls    r3, r3, #8
>    c:   430b            orrs    r3, r1
>    e:   0400            lsls    r0, r0, #16
>   10:   001a            movs    r2, r3   ??? MOVE
>   12:   0003            movs    r3, r0   ??? MOVE
>   14:   78e0            ldrb    r0, [r4, #3]
>   16:   4313            orrs    r3, r2
>   18:   0600            lsls    r0, r0, #24
>   1a:   4318            orrs    r0, r3
>   1c:   f7ff fffe       bl      0 <func>
>   20:   bd10            pop     {r4, pc}
>   22:   46c0            nop                     ; (mov r8, r8)
>   24:   00000000        .word   0x00000000
> 
> Kind Regards, Fredrik

I found the problem root.

We have

  insn 9: p115=p114|p112
  ...
  insn 12: p118=p117|p115
  ...

IRA assigns different regs to p112, p115, and p118

      ...
      Popping a0(r121,l0)  -- assign reg 0
      Popping a1(r118,l0)  -- assign reg 3
      Popping a5(r115,l0)  -- assign reg 2
      Popping a8(r112,l0)  -- assign reg 1
      ...

Therefore LRA generates redundant insn 22 for insn 9 and insn 23 for
insn 12 as an input and the output operands should be in the same
register.

There is no conflicts preventing to assign the same hard reg to p112,
p115, and p118 but IRA does not do this following heuristics taking
other conflict pseudos costs into account.

So the solution is to change the heuristics somehow.  Even if I manage
to do this, the changes should be benchmarked on other architectures
thorougly.  It means the PR will need a lot of time to be fixed but I
am going to work on it.

[Bug target/61578] [4.9 regression] Code size increase for ARM thumb compared to 4.8.x when compiling with -Os

[vogt at linux dot vnet.ibm.com]

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

Dominik Vogt <vogt at linux dot vnet.ibm.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |vogt at linux dot vnet.ibm.com

--- Comment #27 from Dominik Vogt <vogt at linux dot vnet.ibm.com> ---
The patch in comment 22 that was applied on 2015-09-01 with the git commit id
0af99ebfea26293fc900fe9050c5dd514005e4e5 breaks the S/390 compiler (and maybe
other platforms too):

tt.c:
-- snip --
  struct t
  {
    int i;
    void *p;
    void *q;
  };
  void foo (t **g)
  {
    (*g)->p = &((*g)->p);
  }
-- snip --

This code should set "p" to "&p", but actually sets "q" to "&p".  Before the
patch, compiling with "g++ -O2" resulted in this assembly code:

tt.s:
  lg    %r1,0(%r2)  # r1 := *g
  la    %r2,8(%r1)  # r2 := &((*g)->p)
  stg   %r2,8(%r1)  # *r2 := (*g) + 8  <--- GOOD

with the patch it uses r1 for both, effectively doubling the store target's
offset into the structure:

tt.s:
  lg      %r1,0(%r2) # r1 := *g
  la      %r1,8(%r1) # r1 := &((*g)->p)
  stg     %r1,8(%r1) # *(r1 + 8) := (*g) + 8  <--- BAD


RTL details:
============

tt.c.232r.reload (BAD, with patch):
-- snip --
(insn 6 3 7 2 (set (reg/f:DI 1 %r1 [orig:61 *g_2(D) ] [61])
        (mem/f:DI (reg:DI 2 %r2 [ g ]) [1 *g_2(D)+0 S8 A64])) tt.c:9 900
{*movdi_64}
     (nil))
(insn 7 6 13 2 (parallel [
            (set (reg/f:DI 1 %r1 [orig:61 *g_2(D) ] [61])
                (plus:DI (reg/f:DI 1 %r1 [orig:61 *g_2(D) ] [61])
                    (const_int 8 [0x8])))
            (clobber (reg:CC 33 %cc))
        ]) tt.c:9 1171 {*adddi3}
     (nil))
(insn 13 7 10 2 (set (mem/f:DI (plus:DI (reg/f:DI 1 %r1 [orig:61 *g_2(D) ]
[61])
                (const_int 8 [0x8])) [2 _3->p+0 S8 A64])
        (reg/f:DI 1 %r1 [orig:61 *g_2(D) ] [61])) tt.c:9 900 {*movdi_64}
     (nil))
-- snip --


tt.c.232r.reload (GOOD, without patch):
-- snip --
(insn 6 3 12 2 (set (reg/f:DI 1 %r1 [orig:61 *g_2(D) ] [61])
        (mem/f:DI (reg:DI 2 %r2 [ g ]) [1 *g_2(D)+0 S8 A64])) tt.c:9 900
{*movdi_64}
     (nil))
(insn 12 6 7 2 (set (reg:DI 2 %r2 [63])
        (reg/f:DI 1 %r1 [orig:61 *g_2(D) ] [61])) tt.c:9 900 {*movdi_64}
     (nil))
(insn 7 12 13 2 (parallel [
            (set (reg:DI 2 %r2 [63])
                (plus:DI (reg:DI 2 %r2 [63])
                    (const_int 8 [0x8])))
            (clobber (reg:CC 33 %cc))
        ]) tt.c:9 1171 {*adddi3}
     (nil))
(insn 13 7 10 2 (set (mem/f:DI (plus:DI (reg/f:DI 1 %r1 [orig:61 *g_2(D) ]
[61])
                (const_int 8 [0x8])) [2 _3->p+0 S8 A64])
        (reg:DI 2 %r2 [63])) tt.c:9 900 {*movdi_64}
     (nil))
-- snip --


tt.c.231r.ira (GOOD):
-- snip --
(insn 6 3 7 2 (set (reg/f:DI 61 [ *g_2(D) ])
        (mem/f:DI (reg:DI 2 %r2 [ g ]) [1 *g_2(D)+0 S8 A64])) tt.c:9 900
{*movdi_64}
     (expr_list:REG_DEAD (reg:DI 2 %r2 [ g ])
        (nil)))
(insn 7 6 10 2 (parallel [
            (set (mem/f:DI (plus:DI (reg/f:DI 61 [ *g_2(D) ])
                        (const_int 8 [0x8])) [2 _3->p+0 S8 A64])
                (plus:DI (reg/f:DI 61 [ *g_2(D) ])
                    (const_int 8 [0x8])))
            (clobber (reg:CC 33 %cc))
        ]) tt.c:9 1171 {*adddi3}
     (expr_list:REG_DEAD (reg/f:DI 61 [ *g_2(D) ])
        (expr_list:REG_UNUSED (reg:CC 33 %cc)
            (nil))))
-- snip --

[Bug target/61578] [4.9 regression] Code size increase for ARM thumb compared to 4.8.x when compiling with -Os

[vogt at linux dot vnet.ibm.com]

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

--- Comment #28 from Dominik Vogt <vogt at linux dot vnet.ibm.com> ---
Created attachment 36371
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36371&action=edit
Outpout of the reload pass (BAD)

The full output of the reload pass on S/390, showing the behaviour described in
comment 27.

[Bug target/61578] [4.9 regression] Code size increase for ARM thumb compared to 4.8.x when compiling with -Os

[vogt at linux dot vnet.ibm.com]

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

--- Comment #29 from Dominik Vogt <vogt at linux dot vnet.ibm.com> ---
I think I understand what's going on:

Consider the patched code in match_reloads():

+       = (ins[1] < 0 && REG_P (in_rtx)
+          && (int) REGNO (in_rtx) < lra_new_regno_start
+          && find_regno_note (curr_insn, REG_DEAD, REGNO (in_rtx))
+          ? lra_create_new_reg (inmode, in_rtx, goal_class, "")
+          : lra_create_new_reg_with_unique_value (outmode, out_rtx,
+                                                  goal_class, ""));

(1) This code normally makes a unique copy of the register in in_rtx, but if
the register is marked as REG_DEAD in the curr_insn, it just makes a copy of
the register using lra_create_new_reg(), with the same .val and .offset in the
reg_info structure.

(2) Further down in match_reloads, new insns are generated and stored in
*before and *after.  However, the new "after" insn still references the old
register.  In other words, in step (1) the code has made the assumption that
the old register is no longer used, then generates an insn that uses it after
it was marked as REG_DEAD.

(3) Based on the bogus decision in (1), the condition in lra-lives.c decides
that the two registers are identical copies and can be mapped to the same hard
register:

+         && (((src_regno >= FIRST_PSEUDO_REGISTER
+               && (! sparseset_bit_p (pseudos_live, src_regno)
+                   || (dst_regno >= FIRST_PSEUDO_REGISTER
+                       && lra_reg_val_equal_p (src_regno,
+                                               lra_reg_info[dst_regno].val,
+                                              
lra_reg_info[dst_regno].offset))

[Bug target/61578] [4.9 regression] Code size increase for ARM thumb compared to 4.8.x when compiling with -Os

[vmakarov at gcc dot gnu.org]

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

--- Comment #30 from Vladimir Makarov <vmakarov at gcc dot gnu.org> ---
(In reply to Dominik Vogt from comment #29)
> I think I understand what's going on:
> 
> Consider the patched code in match_reloads():
> 
> +       = (ins[1] < 0 && REG_P (in_rtx)
> +          && (int) REGNO (in_rtx) < lra_new_regno_start
> +          && find_regno_note (curr_insn, REG_DEAD, REGNO (in_rtx))
> +          ? lra_create_new_reg (inmode, in_rtx, goal_class, "")
> +          : lra_create_new_reg_with_unique_value (outmode, out_rtx,
> +                                                  goal_class, ""));
> 
> (1) This code normally makes a unique copy of the register in in_rtx, but if
> the register is marked as REG_DEAD in the curr_insn, it just makes a copy of
> the register using lra_create_new_reg(), with the same .val and .offset in
> the reg_info structure.
> 
> (2) Further down in match_reloads, new insns are generated and stored in
> *before and *after.  However, the new "after" insn still references the old
> register.  In other words, in step (1) the code has made the assumption that
> the old register is no longer used, then generates an insn that uses it
> after it was marked as REG_DEAD.
> 
> (3) Based on the bogus decision in (1), the condition in lra-lives.c decides
> that the two registers are identical copies and can be mapped to the same
> hard register:
> 
> +         && (((src_regno >= FIRST_PSEUDO_REGISTER
> +               && (! sparseset_bit_p (pseudos_live, src_regno)
> +                   || (dst_regno >= FIRST_PSEUDO_REGISTER
> +                       && lra_reg_val_equal_p (src_regno,
> +                                               lra_reg_info[dst_regno].val,
> +                                              
> lra_reg_info[dst_regno].offset))

Sorry for breaking s390 port and thanks for the analysis.  I'll try to fix it
on this week.

[Bug target/61578] [4.9 regression] Code size increase for ARM thumb compared to 4.8.x when compiling with -Os

[vmakarov at gcc dot gnu.org]

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

--- Comment #31 from Vladimir Makarov <vmakarov at gcc dot gnu.org> ---
Author: vmakarov
Date: Thu Sep 24 20:40:30 2015
New Revision: 228097

URL: https://gcc.gnu.org/viewcvs?rev=228097&root=gcc&view=rev
Log:
2015-09-24  Vladimir Makarov  <vmakarov@redhat.com>

        PR target/61578
        * ira-color.c (update_allocno_cost): Add parameter.
        (update_costs_from_allocno): Decrease conflict cost.  Pass the new
        parameter.


Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/ira-color.c

[Bug target/61578] [4.9 regression] Code size increase for ARM thumb compared to 4.8.x when compiling with -Os

[vogt at linux dot vnet.ibm.com]

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

--- Comment #32 from Dominik Vogt <vogt at linux dot vnet.ibm.com> ---
Update: We've stepped through the code with gdb and noticed that the change in
lra-lives.c has nothing to do with our observations.  The new condition there
is never executed, so it must be just the change in match_reload().

[Bug target/61578] [4.9 regression] Code size increase for ARM thumb compared to 4.8.x when compiling with -Os

[vogt at linux dot vnet.ibm.com]

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

--- Comment #34 from Dominik Vogt <vogt at linux dot vnet.ibm.com> ---
The patch in comment 33 fixes the s390 regression.  Thanks!