public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "gregpsmith at live dot co.uk" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug target/53938] New: ARM target generates sub-optimal code (extra instructions) on load from memory Date: Thu, 12 Jul 2012 10:58:00 -0000 [thread overview] Message-ID: <bug-53938-4@http.gcc.gnu.org/bugzilla/> (raw) http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53938 Bug #: 53938 Summary: ARM target generates sub-optimal code (extra instructions) on load from memory Classification: Unclassified Product: gcc Version: 4.6.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned@gcc.gnu.org ReportedBy: gregpsmith@live.co.uk Created attachment 27781 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27781 Example C source code We are targetting an embedded device and we do a lot of work accessing an FPGA (but this applies just as well to memory access). It has annoyed me for years that the GCC compiler emits unncessary code, wasting memory and cycles when reading 8 and 16-bit values. The attached script shows opportunities to generate better code. when compiled with: gcc -c -O3 -mcpu=arm946e-s codegen.c It compiles to (I have added comments): <DeviceAccess> mov r2, #0xE0000000 // base address of the device ldrb r1, [r2] // load an unsigned byte, 0 extend ldrb r12, [r2] // load signed byte - WHY NOT ldrsb? and r1, r1, #0xFF // WHAT IS THIS FOR ldrh r3, [r2] // load unsigned short tst r1, #0x80 // if (i & 0x80) movne r1, #0 // i = 0 lsl r12, r12, #24 // sign extend j (but could be avoided) tst r3, #0x80 // if (k & 0x80) ldrh r0, [r2] // load signed short - WHY NOT ldrsh? movne r3, #0 // k = 0 add r1, r1, r12, asr #24 // add sign extended add r3, r1, r3 lsl r0, r0, #16 // sign extend l add r0, r3, r0, asr #16 bx lr There are two issues: 1) There is a completely redundant and r1,r1,#0xff. This does not occur when loading the unsigned short (which is why I have the similar code for loading an unsigned short). 2) There is unneccesary sign extension taking place. ARM has allowed signed loads of 8 and 16-bit values since v4. Spotting this has to be opportunistic as there are offset restrictions. Ideally the code would look like: mov r2, #0xE0000000 // base address of the device ldrb r1, [r2] // load an unsigned byte, 0 extend ldrsb r12, [r2] // load signed byte ldrh r3, [r2] // load unsigned short tst r1, #0x80 // if (i & 0x80) movne r1, #0 // i = 0 tst r3, #0x80 // if (k & 0x80) ldrsh r0, [r2] // load signed short, extend to 32-bits movne r3, #0 // k = 0 add r1, r1, r12 // add sign extended add r3, r1, r3 add r0, r3, r0 bx lr
next reply other threads:[~2012-07-12 10:58 UTC|newest] Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top 2012-07-12 10:58 gregpsmith at live dot co.uk [this message] 2012-07-12 11:27 ` [Bug target/53938] " rguenth at gcc dot gnu.org 2012-07-12 16:10 ` pinskia at gcc dot gnu.org 2012-07-12 19:09 ` gregpsmith at live dot co.uk 2013-08-05 21:20 ` rearnsha at gcc dot gnu.org 2024-01-16 22:13 ` pinskia at gcc dot gnu.org 2024-04-24 13:27 ` rsaxvc at gmail dot com
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-53938-4@http.gcc.gnu.org/bugzilla/ \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).