[Optimization(C++) 12] 인라이닝 유도 기법

인라이닝 유도란 호출 오버헤드를 없애고 상수 전파·최적화 기회를 늘리기 위해, 컴파일러가 함수를 호출부에 펼치도록 유도하는 것을 말합니다. 본 챕터에서는 inline·__forceinline 활용, 인라이닝을 유도하는 코드 패턴, 실패 원인 진단(Tr.02 연계)을 다루고 핫패스 비용을 줄이는 방법을 정리합니다.

이 장을 읽기 전에

완전한 초보자? 이 장은 03장: 추상화 비용 분석의 호출 오버헤드 개념을 전제로 합니다. 인라이닝이 “함수 호출을 호출부에 펼치는 것"이라는 정도만 알면 충분합니다.

이 장의 깊이: 이 장은 심화~전문가를 포괄합니다. inline·__forceinline의 실제 의미부터 시작해, 전문가 구간에서는 인라이닝을 유도하는 코드 패턴, 실패 원인 진단, 코드 크기와의 트레이드오프를 다룹니다. 다루지 않는 것: 컴파일러 인라이닝 리포트·LTO·진단 플래그의 깊은 사용법은 Tr.02 컴파일러 트랙에서 다루며, 이 장은 “코드 레벨에서 무엇을 할 수 있는가"에 집중합니다.

당신의 수준에 맞는 경로

inline 키워드와 컴파일러 최적화

inline은 원래 “이 함수 정의가 여러 번 나와도 ODR(One Definition Rule) 상 하나로 합친다"는 의미였고, 동시에 컴파일러에게 인라인 후보라는 힌트를 줍니다. 실제 인라인 여부는 컴파일러가 크기·복잡도·호출 빈도 등을 보고 결정하므로, inline을 붙여도 인라인되지 않을 수 있고(복잡한 함수·재귀·크기 제한), 반대로 inline 없이도 인라인되는 경우가 많습니다.

“The inline specifier suggests to the implementation that inline substitution of the function body at the point of call is to be preferred.” — ISO C++. 힌트일 뿐, 보장은 아닙니다.

__forceinline(MSVC), attribute((always_inline))(GCC/Clang)는 “가능하면 반드시 인라인해 달라"는 강한 힌트입니다. 그래도 컴파일러는 재귀·매우 큰 함수 등에서는 인라인을 거부할 수 있습니다. 무리하게 강제하면 코드 크기가 커지거나 컴파일이 실패할 수 있으므로, 정말 핫한 작은 함수에만 제한적으로 사용하는 것이 좋습니다.

컴파일러마다 다른 강제 인라인 키워드는 매크로로 한 번 감싸 두어야 GCC·Clang·MSVC에서 모두 컴파일됩니다. __forceinline을 가드 없이 쓰면 GCC/Clang에서 컴파일 오류가 나므로 이식성을 위해 전처리기 분기를 둡니다.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

#if defined(_MSC_VER)
  #define FORCE_INLINE __forceinline
#elif defined(__GNUC__) || defined(__clang__)
  #define FORCE_INLINE inline __attribute__((always_inline))
#else
  #define FORCE_INLINE inline
#endif

// 작은 함수: 인라인 후보에 잘 걸림
inline int add(int a, int b) { return a + b; }

// 강한 힌트: 컴파일러는 재귀·초대형 함수에서는 여전히 거부할 수 있다
FORCE_INLINE int hot_path(int x) { return add(x, 1); }

인라이닝을 유도하는 코드 패턴

• 작은 함수: 한두 줄, 분기가 적을수록 인라인되기 쉽습니다. 복잡한 로직은 작은 함수로 쪼개고, 그중 호출 비용이 문제되는 부분만 인라인되도록 유지합니다.
• 정적 단일 호출: 호출처가 한 곳이면 컴파일러가 인라인한 뒤 사용하지 않는 경로를 제거하기 쉽습니다.
• 헤더에 정의: 템플릿 함수와 inline 함수는 호출하는 쪽에서 정의를 볼 수 있어야 하므로 보통 헤더에 정의합니다. 이렇게 하면 번역 단위(TU) 경계를 넘어서도 인라인 후보가 됩니다.
• LTO(Link Time Optimization): 링크 시점에 여러 오브젝트를 함께 보므로, 다른 TU에 있는 함수도 인라인할 수 있습니다. 핫패스가 여러 TU에 나뉘어 있어도 LTO를 켜면 인라인 기회가 늘어납니다.

인라이닝 실패 원인과 진단 (Tr.02 연계)

컴파일러는 함수 크기·복잡도가 일정 한도를 넘으면 인라인을 하지 않습니다(코드 블로트·컴파일 시간 방지). 가상 함수 호출, 함수 포인터·std::function을 통한 호출은 호출 시점에 실제 타깃을 모르므로 인라인되지 않습니다. **Tr.02(Compiler & Build Optimization)**에서는 -Winline, -fopt-info-inline, 최적화 리포트로 “어떤 함수가 인라인되지 않았는지"와 “이유"를 확인하는 방법을 다룹니다.

GCC에서 -fopt-info-inline-optimized로 인라인된 호출을, -Winline으로 인라인 실패 경고를 확인할 수 있습니다.

1
2
3
4
5
6
7

$ g++ -O2 -fopt-info-inline-optimized hot.cpp
hot.cpp:18:18: optimized: Inlining add/3 into hot_path/4.
hot.cpp:24:9:  optimized: Inlining hot_path/4 into main/5.

$ g++ -O2 -Winline big.cpp
big.cpp:8:5: warning: inlining failed in call to 'int process(const Buffer&)':
             call is unlikely and code size would grow [-Winline]

인라인 성공/실패는 생성된 어셈블리에서도 드러납니다. 호출 전후를 비교하면 call/ret이 사라지고 본문이 펼쳐진 것을 볼 수 있습니다.

1
2
3
4
5
6

; 인라인 전: 호출 명령 + 인자 세팅 + 반환
mov     edi, 41
call    add(int, int)        ; 호출/스택 프레임 비용

; 인라인 후: add(x, 1)이 펼쳐져 한 줄로 (call/ret 제거, 상수 전파 가능)
lea     eax, [rdi+1]

이를 통해 실패 원인(크기·가상성·링크 가시성 등)을 짚고, 필요하면 함수를 쪼개거나 LTO·inline 힌트를 적용할 수 있습니다.

실무 가이드

• 핫패스는 가능하면 작고 단순한 함수로 유지하고, 인라인 경계(다른 TU, 가상 호출, 함수 포인터)를 의식해 설계합니다.
• 인라인 전후로 마이크로벤치마크를 돌려, 인라인이 실제로 호출 비용을 줄이는지 확인합니다. 인라인 후에는 호출 오버헤드가 사라지고 상수 전파 등 추가 최적화가 일어날 수 있습니다.
• 과도한 인라인은 코드 크기를 키워 I-cache 미스를 늘릴 수 있습니다. 핫한 경로만 인라인하고, 나머지는 호출로 두는 균형이 중요합니다.

평가 기준 (학습 성과 목표)

• inline과 __forceinline/always_inline의 차이(힌트 vs 강한 힌트)와 컴파일러가 인라인을 거부하는 경우를 설명할 수 있다.
• 작은 함수·정적 단일 호출·헤더 정의·LTO가 인라이닝에 유리한 패턴임을 설명하고, 핫패스 설계에 적용할 수 있다.
• 인라이닝 실패 원인(크기·가상·함수 포인터·TU 경계)을 진단하고, -Winline·-fopt-info-inline 등 Tr.02 진단 옵션으로 확인할 수 있다.

판단 기준 (언제 쓸고 언제 피할지)

적용 체크리스트: (1) 핫패스는 작고 단순한 함수로. (2) 인라인 전/후 벤치마크. (3) 과도한 인라인으로 코드 크기 증가 시 핫 경로만 제한.

비판적 시각: 한계와 트레이드오프

• inline은 힌트일 뿐이며, 컴파일러가 크기·복잡도 한도로 거부할 수 있다. __forceinline도 재귀·매우 큰 함수에서는 거부될 수 있어, 정말 필요한 작은 함수에만 사용한다.
• 인라인은 코드 블로트와 I-cache에 영향을 주므로, “많이 인라인 = 항상 빠름"이 아니다. 핫 경로와 차가운 경로를 구분하는 것이 좋다.

핵심 요약

용어 정리

벤치마크 결과 해석 가이드

자주 묻는 질문 (FAQ)

Q: inline은 항상 인라인되나요?
A: 아니요. 힌트일 뿐이며, 컴파일러가 크기·복잡도 한도로 거부할 수 있습니다. __forceinline도 재귀·매우 큰 함수에서는 거부될 수 있습니다.

Q: 인라이닝을 유도하는 패턴은?
A: 작은 함수, 정적 단일 호출, 헤더에 정의, LTO 사용이 유리합니다. 가상 함수·함수 포인터·TU 경계는 인라인을 막습니다.

Q: 인라이닝 실패 원인을 어떻게 확인하나요?
A: Tr.02에서 -Winline, -fopt-info-inline, 최적화 리포트로 “어떤 함수가 인라인되지 않았는지"와 “이유"를 확인합니다.

적용 체크리스트 (실무용)

• 핫패스는 작고 단순한 함수로 유지했는가?
• 인라인 전/후 벤치마크했는가?
• 과도한 인라인으로 코드 크기 증가 시 핫 경로만 제한했는가?
• 인라인 실패 원인을 -fopt-info-inline·-Winline으로 확인했는가?

진단 도구 요약

자주 하는 실수

• 큰 함수에 강제 인라인: 컴파일러가 거부하거나 코드 블로트; 작은 핫 함수에만 적용합니다.
• TU 경계 넘어 인라인 기대만: 헤더 정의 또는 LTO 없이는 다른 TU 함수가 인라인되지 않을 수 있습니다.
• 추측만 하고 변경: -fopt-info-inline 등으로 실패 원인을 확인한 뒤 수정합니다.

리팩토링 시 주의

핫패스를 작은 함수로 쪼갤 때 인라인 경계(다른 TU, 가상 호출, 함수 포인터)를 의식합니다. 인라인 전/후 벤치마크로 호출 비용 감소와 코드 크기 증가를 함께 확인합니다.

추가 읽기 및 관련 챕터

• 챕터 11 (예외): noexcept가 인라이닝에 미치는 영향.
• 챕터 13 (variant/optional/expected): 타입 소거·인라인.
• Tr.02: -Winline, -fopt-info-inline, 최적화 리포트.

다음 장에서는

이전 장: 예외 처리 심화 (챕터 11)

std::variant/optional/expected를 다룹니다. 타입 안전 유니온·옵셔널·에러 전달 타입의 성능 특성과 오버헤드, 예외 대안으로서의 expected를 정리합니다. → std::variant/optional/expected (챕터 13)