public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "carrot at google dot com" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug target/42495] New: redundant memory load Date: Fri, 25 Dec 2009 07:51:00 -0000 [thread overview] Message-ID: <bug-42495-17659@http.gcc.gnu.org/bugzilla/> (raw) Compile the attached test case with options -mthumb -Os -fpic, gcc generates: goo: push {r3, r4, r5, lr} ldr r4, .L7 ldr r3, .L7+4 // A .LPIC0: add r4, pc ldr r3, [r4, r3] // B ldr r3, [r3] mov r5, r0 ldr r0, [r3] cmp r0, #0 beq .L2 mov r1, r5 bl foo .L2: ldr r3, [r5] mov r0, #0 cmp r3, #0 beq .L3 ldr r2, .L7+4 // C ldr r2, [r4, r2] // D ldr r2, [r2, #4] ldr r2, [r2] cmp r3, r2 beq .L3 ldr r0, [r3] .L3: @ sp needed for prologue pop {r3, r4, r5} pop {r1} bx r1 .L7: .word _GLOBAL_OFFSET_TABLE_-(.LPIC0+4) .word gObj(GOT) Notice instructions A,B,C,D, they load the address of global variable gObj twice. When compiled with options -mthumb -O2 -fpic, gcc generates: goo: push {r4, r5, r6, lr} ldr r4, .L8 ldr r5, .L8+4 // E .LPIC0: add r4, pc ldr r3, [r4, r5] // F ldr r3, [r3] mov r6, r0 ldr r0, [r3] cmp r0, #0 bne .L7 .L2: ldr r3, [r6] mov r0, #0 cmp r3, #0 beq .L3 ldr r2, [r4, r5] // G ldr r2, [r2, #4] // H ldr r2, [r2] cmp r2, r3 beq .L3 ldr r0, [r3] .L3: @ sp needed for prologue pop {r4, r5, r6} pop {r1} bx r1 .L7: mov r1, r6 bl foo b .L2 .L9: .align 2 .L8: .word _GLOBAL_OFFSET_TABLE_-(.LPIC0+4) .word gObj(GOT) Instructions E,F,G do the same thing, but with one less memory load instruction. It uses the same number of instructions. -Os should do the same optimization. Actually -O2 result is still not optimal. If we store the result of F into r4, we can directly use r4 in instruction H, so G can also be removed. -- Summary: redundant memory load Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: carrot at google dot com GCC build triplet: i686-linux GCC host triplet: i686-linux GCC target triplet: arm-eabi http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42495
next reply other threads:[~2009-12-25 7:51 UTC|newest] Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top 2009-12-25 7:51 carrot at google dot com [this message] 2009-12-25 7:51 ` [Bug target/42495] " carrot at google dot com 2009-12-25 7:52 ` carrot at google dot com 2009-12-31 15:35 ` rguenth at gcc dot gnu dot org 2010-03-19 15:12 ` ramana at gcc dot gnu dot org 2010-03-21 9:18 ` carrot at google dot com 2010-06-08 10:41 ` mkuvyrkov at gcc dot gnu dot org 2010-07-27 19:35 ` mkuvyrkov at gcc dot gnu dot org 2010-07-27 19:38 ` mkuvyrkov at gcc dot gnu dot org 2010-07-27 19:42 ` mkuvyrkov at gcc dot gnu dot org 2010-07-27 19:45 ` mkuvyrkov at gcc dot gnu dot org 2010-07-27 19:48 ` mkuvyrkov at gcc dot gnu dot org 2010-07-27 21:07 ` mkuvyrkov at gcc dot gnu dot org 2010-07-27 21:11 ` mkuvyrkov at gcc dot gnu dot org
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-42495-17659@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).