http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59535
--- Comment #6 from Richard Earnshaw <rearnsha at gcc dot gnu.org> --- Created attachment 31457 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31457&action=edit Another testcase Another testcase, but this one has some obvious examples of poor behaviour for -Os. In addtion to the options used on the previous case, this might need -fno-strict-aliasing -fno-common -fomit-frame-pointer -fno-strength-reduce Example one, spilling a value and then keeping a copy in a hard reg over a call. mov r5, r1 <= R1 copied to R5 sub sp, sp, #28 str r1, [sp, #8] <= And spilled to the stack mov r2, #12 mov r1, #0 mov r4, r0 bl memset mov r3, #2 mov r2, r5 <= Could reload from the stack instead Example two, use of multiple reloads to use high register: ldr r3, [sp, #4] mov ip, r3 <= Copying value into high register add ip, ip, r5 <= Arithmetic mov r3, ip <= Copying result back to original register str r3, [sp, #4] ldr r3, [sp, #12] mov ip, r3 <= And IP is dead anyway... In this case, mov ip, r3 add ip, ip, r5 mov r3, ip can be replaced entirely with add r3, r5 saving two completely unnecessary MOV instructions. Third, related case, mov r1, #12 mov ip, r1 add ip, ip, r4 mov r1, ip Could be done either as mov r1, #12 add r1, r4 mov ip, r1 or mov r1, r4 add r1, #12 mov ip, r1 both saving one instruction, or even two if the value doesn't really need copying to a high reg.
