From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 84718 invoked by alias); 3 Sep 2015 05:16:57 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 84660 invoked by uid 48); 3 Sep 2015 05:16:53 -0000 From: "fredrik.hederstierna@securitas-direct.com" To: gcc-bugs@gcc.gnu.org Subject: [Bug target/61578] [4.9 regression] Code size increase for ARM thumb compared to 4.8.x when compiling with -Os Date: Thu, 03 Sep 2015 05:16:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: target X-Bugzilla-Version: 4.9.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: fredrik.hederstierna@securitas-direct.com X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: 4.9.4 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: 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/msg00223.txt.bz2 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61578 --- Comment #23 from Fredrik Hederstierna --- 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 : 0: b508 push {r3, lr} 2: 4b07 ldr r3, [pc, #28] ; (20 ) 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 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 : 0: b510 push {r4, lr} 2: 4c08 ldr r4, [pc, #32] ; (24 ) 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 20: bd10 pop {r4, pc} 22: 46c0 nop ; (mov r8, r8) 24: 00000000 .word 0x00000000 Kind Regards, Fredrik