https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67213
Bug ID: 67213 Summary: When compiling for size with -Os loops can get bigger after peeling Product: gcc Version: 5.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: fredrik.hederstie...@securitas-direct.com Target Milestone: --- When compiling thumb1 code for size with -Os some loops can be larger due to complete peeling. Example code: extern char data[10]; void test_iter_2(void) { int i; for (i = 0; i < 2; i++) { data[i] = i; } } void test_iter_6(void) { int i; for (i = 0; i < 6; i++) { data[i] = i; } } void test_iter_7(void) { int i; for (i = 0; i < 7; i++) { data[i] = i; } } It will compile to 00000000 <test_iter_2>: 0: e3a02000 mov r2, #0 4: e59f300c ldr r3, [pc, #12] ; 18 <test_iter_2+0x18> 8: e5c32000 strb r2, [r3] c: e3a02001 mov r2, #1 10: e5c32001 strb r2, [r3, #1] 14: e12fff1e bx lr 18: 00000000 .word 0x00000000 0000001c <test_iter_6>: 1c: e3a02000 mov r2, #0 20: e59f302c ldr r3, [pc, #44] ; 54 <test_iter_6+0x38> 24: e5c32000 strb r2, [r3] 28: e3a02001 mov r2, #1 2c: e5c32001 strb r2, [r3, #1] 30: e3a02002 mov r2, #2 34: e5c32002 strb r2, [r3, #2] 38: e3a02003 mov r2, #3 3c: e5c32003 strb r2, [r3, #3] 40: e3a02004 mov r2, #4 44: e5c32004 strb r2, [r3, #4] 48: e3a02005 mov r2, #5 4c: e5c32005 strb r2, [r3, #5] 50: e12fff1e bx lr 54: 00000000 .word 0x00000000 00000058 <test_iter_7>: 58: e3a03000 mov r3, #0 5c: e59f2010 ldr r2, [pc, #16] ; 74 <test_iter_7+0x1c> 60: e7c33002 strb r3, [r3, r2] 64: e2833001 add r3, r3, #1 68: e3530007 cmp r3, #7 6c: 1afffffb bne 60 <test_iter_7+0x8> 70: e12fff1e bx lr 74: 00000000 .word 0x00000000 The unrolling of iter_6 seems to be controlled by default: --param max-completely-peel-times=5 if changing to --param max-completely-peel-times=0 code for iter_6 gets ok, but then iter_2 get larger. 00000000 <test_iter_2>: 0: e3a03000 mov r3, #0 4: e59f2010 ldr r2, [pc, #16] ; 1c <test_iter_2+0x1c> 8: e7c33002 strb r3, [r3, r2] c: e2833001 add r3, r3, #1 10: e3530002 cmp r3, #2 14: 1afffffb bne 8 <test_iter_2+0x8> 18: e12fff1e bx lr 1c: 00000000 .word 0x00000000 00000020 <test_iter_6>: 20: e3a03000 mov r3, #0 24: e59f2010 ldr r2, [pc, #16] ; 3c <test_iter_6+0x1c> 28: e7c33002 strb r3, [r3, r2] 2c: e2833001 add r3, r3, #1 30: e3530006 cmp r3, #6 34: 1afffffb bne 28 <test_iter_6+0x8> 38: e12fff1e bx lr 3c: 00000000 .word 0x00000000 00000040 <test_iter_7>: 40: e3a03000 mov r3, #0 44: e59f2010 ldr r2, [pc, #16] ; 5c <test_iter_7+0x1c> 48: e7c33002 strb r3, [r3, r2] 4c: e2833001 add r3, r3, #1 50: e3530007 cmp r3, #7 54: 1afffffb bne 48 <test_iter_7+0x8> 58: e12fff1e bx lr 5c: 00000000 .word 0x00000000 I guess its a trade off between number allowed unrolls and expected code size growth/decrease. Though it could maybe be detected that code size growth in this case. Attach toolchain build script and code.