임베디드 컴파일러 최적화 분석 — -O0~-O3·-Os·-LTO 비교

#한 줄 요약

“-O 레벨은 컴파일러에게 얼마나 적극적으로 변환할지를 알려 줍니다.” 임베디드는 보통 -Os(크기) 또는 -O2(속도)에서 시작합니다.

#어떤 상황에서 쓰나

• Flash가 부족해 코드 크기를 줄여야 할 때
• 핫 루프 성능을 끌어올려야 할 때
• 디버깅이 안 될 정도로 변수가 사라졌을 때
• LTO를 적용했더니 갑자기 코드가 깨질 때

#핵심 개념

#1) -O 레벨

각 레벨은 사실 수십 개의 개별 옵션(-finline-functions 등)의 묶음입니다.

#2) 각 레벨의 효과 비교

1
int sum(const int *arr, int n) {
2
    int s = 0;
3
    for (int i = 0; i < n; i++) s += arr[i];
4
    return s;
5
}

-O0:

1
sum:
2
    push    {r4, r5, r7, lr}
3
    mov     r5, r0
4
    mov     r4, r1
5
    movs    r2, #0           @ s = 0
6
    str     r2, [r7, #4]
7
    movs    r2, #0
8
    str     r2, [r7]         @ i = 0
9
.L3:
10
    ldr     r2, [r7]
11
    cmp     r2, r4
12
    bge     .L2
13
    ...

-O2:

1
sum:
2
    cmp     r1, #0
3
    ble     .L4
4
    mov     r3, #0
5
    mov     r2, #0
6
.L3:
7
    ldr     ip, [r0, r3, lsl #2]
8
    add     r2, r2, ip
9
    add     r3, r3, #1
10
    cmp     r3, r1
11
    bne     .L3
12
    mov     r0, r2
13
    bx      lr

-O0은 모든 변수를 stack에 저장, -O2는 register 활용.

#3) -Os — 크기 최적화

코드 크기를 최소화하려고 inline expansion을 제한합니다. -O2에서 20 ~ 30% 더 작아지지만, 약간 느려질 수 있습니다.

hello.c 빌드 결과:

• -O0: 28 KB
• -Os: 8 KB
• -O2: 12 KB
• -O3: 14 KB

#4) -Og — 디버그 친화

-O0은 너무 느리고, -O2는 변수가 사라져 디버깅이 어렵습니다. -Og는 그 사이 절충입니다.

• Variable lifetime이 source와 비슷하게 유지
• Inline expansion 최소화
• Step-through가 자연스러움

개발 중에는 -Og -g3이 가장 편합니다.

#5) LTO (Link-Time Optimization)

-flto로 활성화합니다. 모든 .o 파일을 합쳐서 최적화하므로, file 경계를 넘는 inline·dead code 제거가 가능합니다.

1
arm-none-eabi-gcc -O2 -flto -c a.c -o a.o
2
arm-none-eabi-gcc -O2 -flto -c b.c -o b.o
3
arm-none-eabi-gcc -O2 -flto a.o b.o -o app.elf

10 ~ 30% 추가 크기/속도 향상이 흔합니다. 단점은 빌드 시간 증가와 일부 hardware-specific 코드(예: 인라인 어셈블리)에서 가끔 문제 발생.

#6) PGO (Profile-Guided Optimization)

실제 실행 profile을 모아 컴파일러에 알려주는 기법. 임베디드에서는 host에서 측정 후 다시 빌드가 어려워 거의 안 씁니다.

#코드 / 실제 사용 예

함수별 최적화 옵션 제어:

1
// 이 함수만 -O3로 (속도 critical)
2
__attribute__((optimize("O3")))
3
void hot_loop(void) {
4
    for (int i = 0; i < N; i++) /* ... */;
5
}
6

7
// 디버깅 중 이 함수만 -O0로
8
__attribute__((optimize("O0")))
9
void debug_me(void) {
10
    int x = 5;
11
    // breakpoint
12
}
13

14
// inline 강제 또는 금지
15
static inline __attribute__((always_inline))
16
int small_helper(int x) { return x + 1; }
17

18
__attribute__((noinline))
19
void never_inline_me(void) { ... }

빌드 옵션 표준 예시:

1
# Debug
2
CFLAGS_DEBUG = -Og -g3 -DDEBUG
3

4
# Release
5
CFLAGS_RELEASE = -Os -g3 -flto -ffunction-sections -fdata-sections
6

7
# Profile/measure
8
CFLAGS_PROFILE = -O2 -g3 -pg

#측정 / 비교

#자주 보는 함정

⚠️ -O0으로만 빌드하고 release

flash 크기와 속도가 release보다 2 ~ 3배 차이. release는 반드시 -Os 또는 -O2.

⚠️ -O2 후 변수가 optimized out

gdb에서 <optimized out>이 보입니다. volatile를 붙이거나 -Og로 디버깅.

⚠️ LTO로 inline assembly가 깨짐

asm constraint이 file 단위로 잡혔는데 LTO가 cross-file inline을 하면서 깨지는 경우. 해당 함수만 __attribute__((noinline)) 또는 optimize("no-lto").

⚠️ -Ofast 사용 후 NaN 처리 깨짐

-Ofast는 -ffast-math를 포함, IEEE 표준 위반 허용. NaN, Inf 처리에 의존하는 코드는 깨짐.

⚠️ volatile이 부족해 HW 접근 reorder

-O2는 적극적으로 reorder합니다. peripheral register는 반드시 volatile (CMSIS 헤더가 이미 해 줌).

⚠️ Inline 함수가 너무 작아도 inline 안 됨

-Os에서는 inline이 보수적. __attribute__((always_inline)) 또는 -finline-limit=N으로 조정.

#정리

• -O 레벨은 컴파일러 최적화의 적극성을 정합니다.
• 임베디드 표준은 release -Os 또는 -O2, debug -Og.
• -O3는 vectorize 포함, 임베디드에서는 hotspot에만.
• LTO(-flto)는 cross-file 최적화로 10 ~ 30% 추가 이득.
• 함수별 attribute로 개별 최적화 제어 가능.
• volatile, inline 제어, debug 친화를 옵션 선택의 함정에 주의.

다음 편에서는 맵 파일 분석을 다룹니다. 빌드 후 메모리 사용을 한눈에 보는 방법입니다.

#관련 항목

• 3-02: 컴파일 4단계
• 3-08: 메모리 레이아웃
• 3-10: 맵 파일 분석
• 더 깊이 — Embedded C++ for Real Systems: 컴파일러 플래그