Conclusion
The conclusion comes first
1.Declaring a local loop variable inside a
forloop does not cause repeated stack operations with either the AC6 or GCC compiler — the same two stack offsets are simply reused. With optimization enabled, the assembly is exactly identical whenever the two forms are logically equivalent.
In fact, declaring the loop variable in the
forloop itself is an excellent practice. Hoisting all local variable declarations to the top of the function, on the other hand, is a deoptimization, or no optimization at all, depending on the optimization level and the compiler.By extension, if you're chasing peak performance, declare a local variable only in the branch where it is actually used.
All the tests below were compiled for the STM32H7.
Stack behavior of local variables with this pattern
for(int i = 0; i < 50; i++)
{
for(int j = 0; j < 50; j++)
{
HAL_Delay(1);
}
}
Intuitively, every time the outer loop runs, a local variable j is declared. So does this cause repeated stack allocations?
Here's the disassembly
0x0000001e: LDR r0,[sp,#0]
0x00000020: STR r0,[sp,#8]
0x00000022: B {pc}+0x2 ; 0x24
0x00000024: LDR r0,[sp,#8]
0x00000026: CMP r0,#0x31
0x00000028: BGT {pc}+0x2c ; 0x54
0x0000002a: B {pc}+0x2 ; 0x2c
0x0000002c: MOVS r0,#0
0x0000002e: STR r0,[sp,#4]
0x00000030: B {pc}+0x2 ; 0x32
0x00000032: LDR r0,[sp,#4]
0x00000034: CMP r0,#0x31
0x00000036: BGT {pc}+0x14 ; 0x4a
0x00000038: B {pc}+0x2 ; 0x3a
0x0000003a: MOVS r0,#1
0x0000003c: BL HAL_Delay
0x00000040: B {pc}+0x2 ; 0x42
0x00000042: LDR r0,[sp,#4]
0x00000044: ADDS r0,#1
0x00000046: STR r0,[sp,#4]
0x00000048: B {pc}-0x16 ; 0x32
0x0000004a: B {pc}+0x2 ; 0x4c
0x0000004c: LDR r0,[sp,#8]
0x0000004e: ADDS r0,#1
0x00000050: STR r0,[sp,#8]
0x00000052: B {pc}-0x2e ; 0x24
The outer loop
Not our main focus — it just uses branch instructions to run the inner loop 50 times.
0x0000001e: LDR r0,[sp,#0]
0x00000020: STR r0,[sp,#8]
0x00000022: B {pc}+0x2 ; 0x24
0x00000024: LDR r0,[sp,#8]
0x00000026: CMP r0,#0x31
0x00000028: BGT {pc}+0x2c ; 0x54
0x0000002a: B {pc}+0x2 ; 0x2c
; .....内层循环
0x0000004a: B {pc}+0x2 ; 0x4c
0x0000004c: LDR r0,[sp,#8]
0x0000004e: ADDS r0,#1
0x00000050: STR r0,[sp,#8]
0x00000052: B {pc}-0x2e ; 0x24
The inner loop
0x0000002c: MOVS r0,#0
0x0000002e: STR r0,[sp,#4]
0x00000030: B {pc}+0x2 ; 0x32
0x00000032: LDR r0,[sp,#4]
0x00000034: CMP r0,#0x31
0x00000036: BGT {pc}+0x14 ; 0x4a
0x00000038: B {pc}+0x2 ; 0x3a
0x0000003a: MOVS r0,#1
0x0000003c: BL HAL_Delay
0x00000040: B {pc}+0x2 ; 0x42
0x00000042: LDR r0,[sp,#4]
0x00000044: ADDS r0,#1
0x00000046: STR r0,[sp,#4]
0x00000048: B {pc}-0x16 ; 0x32
The two instructions at 0x2c and 0x2e write 0 to the stack slot at sp+4.
It then uses increment and branch instructions to execute the loop 50 times.
In other words, each execution of the outer loop body runs this same logic against the sp+4 slot, while the outer loop itself targets sp+8 every iteration.
What if the local variables are declared up front?
Change the code to:
int i = 0;
int j = 0;
for(i = 0; i < 50; i++)
{
for(j = 0; j < 50; j++)
{
HAL_Delay(1);
}
}
Here's the disassembly
0x0000001e: LDR r0,[sp,#0]
0x00000020: STR r0,[sp,#8]
0x00000022: STR r0,[sp,#4]
0x00000024: STR r0,[sp,#8]
0x00000026: B {pc}+0x2 ; 0x28
0x00000028: LDR r0,[sp,#8]
0x0000002a: CMP r0,#0x31
0x0000002c: BGT {pc}+0x2c ; 0x58
0x0000002e: B {pc}+0x2 ; 0x30
0x00000030: MOVS r0,#0
0x00000032: STR r0,[sp,#4]
0x00000034: B {pc}+0x2 ; 0x36
0x00000036: LDR r0,[sp,#4]
0x00000038: CMP r0,#0x31
0x0000003a: BGT {pc}+0x14 ; 0x4e
0x0000003c: B {pc}+0x2 ; 0x3e
0x0000003e: MOVS r0,#1
0x00000040: BL HAL_Delay
0x00000044: B {pc}+0x2 ; 0x46
0x00000046: LDR r0,[sp,#4]
0x00000048: ADDS r0,#1
0x0000004a: STR r0,[sp,#4]
0x0000004c: B {pc}-0x16 ; 0x36
0x0000004e: B {pc}+0x2 ; 0x50
0x00000050: LDR r0,[sp,#8]
0x00000052: ADDS r0,#1
0x00000054: STR r0,[sp,#8]
0x00000056: B {pc}-0x2e ; 0x28
As you can see, the loop portion (0x26–0x56) is no different from the earlier version (0x22–0x52); it only adds two instructions that zero out sp+4 and sp+8 — a deoptimization.
Does making the loop more complex change anything?
The code below, together with its disassembly, uses sp+8 and sp+12, and still produces no excessive stack operations:
int test = 0;
for(int i = 0; i < 50; i++)
{
for(int j = 0; j < 50; j++)
{
if((test & 0x01) == 0)
HAL_Delay(1);
else
HAL_Delay(2);
}
test++;
}
0x0000001e: 9801 .. LDR r0,[sp,#4]
0x00000020: 9004 .. STR r0,[sp,#0x10]
0x00000022: 9003 .. STR r0,[sp,#0xc]
0x00000024: e7ff .. B {pc}+0x2 ; 0x26
0x00000026: 9803 .. LDR r0,[sp,#0xc]
0x00000028: 2831 1( CMP r0,#0x31
0x0000002a: dc21 !. BGT {pc}+0x46 ; 0x70
0x0000002c: e7ff .. B {pc}+0x2 ; 0x2e
0x0000002e: 2000 . MOVS r0,#0
0x00000030: 9002 .. STR r0,[sp,#8]
0x00000032: e7ff .. B {pc}+0x2 ; 0x34
0x00000034: 9802 .. LDR r0,[sp,#8]
0x00000036: 2831 1( CMP r0,#0x31
0x00000038: dc12 .. BGT {pc}+0x28 ; 0x60
0x0000003a: e7ff .. B {pc}+0x2 ; 0x3c
0x0000003c: f89d0010 .... LDRB r0,[sp,#0x10]
0x00000040: 07c0 .. LSLS r0,r0,#31
0x00000042: b920 . CBNZ r0,{pc}+0xc ; 0x4e
0x00000044: e7ff .. B {pc}+0x2 ; 0x46
0x00000046: 2001 . MOVS r0,#1
0x00000048: f7fffffe .... BL HAL_Delay
0x0000004c: e003 .. B {pc}+0xa ; 0x56
0x0000004e: 2002 . MOVS r0,#2
0x00000050: f7fffffe .... BL HAL_Delay
0x00000054: e7ff .. B {pc}+0x2 ; 0x56
0x00000056: e7ff .. B {pc}+0x2 ; 0x58
0x00000058: 9802 .. LDR r0,[sp,#8]
0x0000005a: 3001 .0 ADDS r0,#1
0x0000005c: 9002 .. STR r0,[sp,#8]
0x0000005e: e7e9 .. B {pc}-0x2a ; 0x34
0x00000060: 9804 .. LDR r0,[sp,#0x10]
0x00000062: 3001 .0 ADDS r0,#1
0x00000064: 9004 .. STR r0,[sp,#0x10]
0x00000066: e7ff .. B {pc}+0x2 ; 0x68
0x00000068: 9803 .. LDR r0,[sp,#0xc]
0x0000006a: 3001 .0 ADDS r0,#1
0x0000006c: 9003 .. STR r0,[sp,#0xc]
0x0000006e: e7da .. B {pc}-0x48 ; 0x26
Moving the declarations up front, as in the code below, is again a deoptimization:
int test = 0;
int i = 0;
int j = 0;
for(i = 0; i < 50; i++)
{
for(j = 0; j < 50; j++)
{
if((test & 0x01) == 0)
HAL_Delay(1);
else
HAL_Delay(2);
}
test++;
}
0x0000001e: 9801 .. LDR r0,[sp,#4]
0x00000020: 9004 .. STR r0,[sp,#0x10]
0x00000022: 9003 .. STR r0,[sp,#0xc]
0x00000024: 9002 .. STR r0,[sp,#8]
0x00000026: 9003 .. STR r0,[sp,#0xc]
0x00000028: e7ff .. B {pc}+0x2 ; 0x2a
0x0000002a: 9803 .. LDR r0,[sp,#0xc]
0x0000002c: 2831 1( CMP r0,#0x31
0x0000002e: dc21 !. BGT {pc}+0x46 ; 0x74
0x00000030: e7ff .. B {pc}+0x2 ; 0x32
0x00000032: 2000 . MOVS r0,#0
0x00000034: 9002 .. STR r0,[sp,#8]
0x00000036: e7ff .. B {pc}+0x2 ; 0x38
0x00000038: 9802 .. LDR r0,[sp,#8]
0x0000003a: 2831 1( CMP r0,#0x31
0x0000003c: dc12 .. BGT {pc}+0x28 ; 0x64
0x0000003e: e7ff .. B {pc}+0x2 ; 0x40
0x00000040: f89d0010 .... LDRB r0,[sp,#0x10]
0x00000044: 07c0 .. LSLS r0,r0,#31
0x00000046: b920 . CBNZ r0,{pc}+0xc ; 0x52
0x00000048: e7ff .. B {pc}+0x2 ; 0x4a
0x0000004a: 2001 . MOVS r0,#1
0x0000004c: f7fffffe .... BL HAL_Delay
0x00000050: e003 .. B {pc}+0xa ; 0x5a
0x00000052: 2002 . MOVS r0,#2
0x00000054: f7fffffe .... BL HAL_Delay
0x00000058: e7ff .. B {pc}+0x2 ; 0x5a
0x0000005a: e7ff .. B {pc}+0x2 ; 0x5c
0x0000005c: 9802 .. LDR r0,[sp,#8]
0x0000005e: 3001 .0 ADDS r0,#1
0x00000060: 9002 .. STR r0,[sp,#8]
0x00000062: e7e9 .. B {pc}-0x2a ; 0x38
0x00000064: 9804 .. LDR r0,[sp,#0x10]
0x00000066: 3001 .0 ADDS r0,#1
0x00000068: 9004 .. STR r0,[sp,#0x10]
0x0000006a: e7ff .. B {pc}+0x2 ; 0x6c
0x0000006c: 9803 .. LDR r0,[sp,#0xc]
0x0000006e: 3001 .0 ADDS r0,#1
0x00000070: 9003 .. STR r0,[sp,#0xc]
0x00000072: e7da .. B {pc}-0x48 ; 0x2a
With optimization enabled
O1
Still the complex loop from above.
Declared in the for:
0x00000014: 2400 .$ MOVS r4,#0
0x00000016: bf00 .. NOP
0x00000018: f0040501 .... AND r5,r4,#1
0x0000001c: 2632 2& MOVS r6,#0x32
0x0000001e: bf00 .. NOP
0x00000020: 2002 . MOVS r0,#2
0x00000022: 2d00 .- CMP r5,#0
0x00000024: bf08 .. IT EQ
0x00000026: 2001 . MOVEQ r0,#1
0x00000028: f7fffffe .... BL HAL_Delay
0x0000002c: 3e01 .> SUBS r6,#1
0x0000002e: d1f7 .. BNE {pc}-0xe ; 0x20
0x00000030: 3401 .4 ADDS r4,#1
0x00000032: 2c32 2, CMP r4,#0x32
0x00000034: d1f0 .. BNE {pc}-0x1c ; 0x18
With the declarations hoisted, the two are completely identical:
0x00000014: 2400 .$ MOVS r4,#0
0x00000016: bf00 .. NOP
0x00000018: f0040501 .... AND r5,r4,#1
0x0000001c: 2632 2& MOVS r6,#0x32
0x0000001e: bf00 .. NOP
0x00000020: 2002 . MOVS r0,#2
0x00000022: 2d00 .- CMP r5,#0
0x00000024: bf08 .. IT EQ
0x00000026: 2001 . MOVEQ r0,#1
0x00000028: f7fffffe .... BL HAL_Delay
0x0000002c: 3e01 .> SUBS r6,#1
0x0000002e: d1f7 .. BNE {pc}-0xe ; 0x20
0x00000030: 3401 .4 ADDS r4,#1
0x00000032: 2c32 2, CMP r4,#0x32
0x00000034: d1f0 .. BNE {pc}-0x1c ; 0x18
O2
Still the complex loop from above.
Declared in the for:
0x00000014: 2500 .% MOVS r5,#0
0x00000016: bf00 .. NOP
0x00000018: 2402 .$ MOVS r4,#2
0x0000001a: 2632 2& MOVS r6,#0x32
0x0000001c: 07e8 .. LSLS r0,r5,#31
0x0000001e: bf08 .. IT EQ
0x00000020: 2401 .$ MOVEQ r4,#1
0x00000022: bf00 .. NOP
0x00000024: 4620 F MOV r0,r4
0x00000026: f7fffffe .... BL HAL_Delay
0x0000002a: 3e01 .> SUBS r6,#1
0x0000002c: d1fa .. BNE {pc}-0x8 ; 0x24
0x0000002e: 3501 .5 ADDS r5,#1
0x00000030: 2d32 2- CMP r5,#0x32
0x00000032: d1f1 .. BNE {pc}-0x1a ; 0x18
With the declarations hoisted, the two are completely identical:
0x00000014: 2500 .% MOVS r5,#0
0x00000016: bf00 .. NOP
0x00000018: 2402 .$ MOVS r4,#2
0x0000001a: 2632 2& MOVS r6,#0x32
0x0000001c: 07e8 .. LSLS r0,r5,#31
0x0000001e: bf08 .. IT EQ
0x00000020: 2401 .$ MOVEQ r4,#1
0x00000022: bf00 .. NOP
0x00000024: 4620 F MOV r0,r4
0x00000026: f7fffffe .... BL HAL_Delay
0x0000002a: 3e01 .> SUBS r6,#1
0x0000002c: d1fa .. BNE {pc}-0x8 ; 0x24
0x0000002e: 3501 .5 ADDS r5,#1
0x00000030: 2d32 2- CMP r5,#0x32
0x00000032: d1f1 .. BNE {pc}-0x1a ; 0x18
O3
O3 isn't worth discussing — the loop is fully unrolled.
Under GCC
Defining the local variables up front is likewise a deoptimization.
Locals declared inside the for: 20 instructions
Locals declared up front: 24 instructions
