# LLVM: 문제점들

> Clean Markdown view of GeekNews topic #25787. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=25787](https://news.hada.io/topic?id=25787)
- GeekNews Markdown: [https://news.hada.io/topic/25787.md](https://news.hada.io/topic/25787.md)
- Type: GN+
- Author: [neo](https://news.hada.io/@neo)
- Published: 2026-01-13T17:32:55+09:00
- Updated: 2026-01-13T17:32:55+09:00
- Original source: [npopov.com](https://www.npopov.com/2026/01/11/LLVM-The-bad-parts.html)
- Points: 4
- Comments: 1

## Topic Body

- **LLVM 프로젝트의 구조적 한계와 기술적 부채**를 다각도로 분석하며, 개선이 필요한 영역을 구체적으로 지적  
- **리뷰 부족**, **API 불안정성**, **빌드 및 컴파일 시간**, **CI 불안정성** 등 대규모 오픈소스 프로젝트 운영상의 병목 현상 제시  
- **IR 설계 문제**로는 undef 값 처리, 제약 조건 인코딩, 부동소수점 의미 체계, 명세 불완전성 등을 포함  
- **백엔드 이질성**, **ABI 처리 혼란**, **GlobalISel·패스 매니저 이행 지연** 등 장기적 구조 문제 지적  
- LLVM의 현황을 부정하기보다, **지속적 개선과 기여 확대의 기회**로 제시함  

---

### 주요 구조적 문제

- **리뷰 역량 부족**이 가장 큰 병목으로 지적됨  
  - 코드 작성자는 많지만 리뷰어가 부족해, 검증되지 않은 변경이 병합되는 사례 발생  
  - 리뷰 요청이 작성자 책임인 구조로 인해 신규 기여자가 적절한 리뷰어를 찾기 어려움  
  - Rust의 **PR 자동 할당 시스템** 도입이 개선 방안으로 언급됨  

- **API 및 IR의 잦은 변경(Churn)** 이 사용자에게 부담  
  - C API는 비교적 안정적이지만, C++ API는 자주 변경되어 프런트엔드·백엔드 유지보수 비용 증가  
  - “**Upstream or GTFO**” 철학으로 인해 비공유 코드가 의사결정에 반영되지 않음  

- **빌드 시간 과다** 문제  
  - LLVM은 250만 줄 이상의 C++ 코드로 구성되어 빌드 시간이 매우 길며, 디버그 빌드 시 메모리·디스크 사용량 급증  
  - **사전 컴파일 헤더(PCH)** , **dylib 기본 빌드**, **테스트 데몬화** 등이 개선책으로 논의됨  

- **CI 불안정성**  
  - 200개 이상의 빌드봇이 다양한 환경에서 테스트하지만, 항상 “녹색 상태”를 유지하지 못함  
  - flaky 테스트와 빌드봇 문제로 경고 신호가 희석되어 실제 오류 탐지가 어려움  
  - PR 사전 테스트 도입으로 일부 개선되었으나, 근본적 해결은 미흡  

- **엔드투엔드 테스트 부족**  
  - 개별 최적화 단위 테스트는 충실하지만, 전체 파이프라인이나 백엔드 결합 테스트는 거의 없음  
  - `llvm-test-suite`는 존재하나 기본 연산·데이터형 조합을 충분히 다루지 못함  

### 백엔드 및 성능 관련 문제

- **백엔드 간 이질성**  
  - 중간단계는 통합되어 있으나, 백엔드는 각 타깃별로 독립적 수정이 많아 **중복과 분기 증가**  
  - 공통 최적화 대신 타깃 전용 훅을 추가하는 경향 존재  

- **컴파일 시간**  
  - JIT 및 대규모 IR 생성 언어(Rust, C++)에서 느림  
  - `-O0` 빌드가 특히 느리며, **TPDE 백엔드**는 최대 10~20배 빠른 대안으로 제시됨  

- **성능 추적 부재**  
  - 공식적인 **런타임 성능 추적 인프라**가 없음  
  - LNT 시스템은 작동 불안정·UX 문제·데이터 부족 등으로 실효성 낮음  

### IR 설계 문제

- **undef 값 처리의 복잡성**  
  - 사용마다 다른 값을 가질 수 있어 최적화 시 오류 유발  
  - 향후 **poison 값**으로 대체 가능성이 있으나, 메모리 내 poison 처리가 아직 미비  

- **명세 불완전성과 비정합성**  
  - 오래된 미해결 오동작 사례 존재  
  - **provenance 모델** 등 설계적 난제 존재  
  - 이를 해결하기 위해 **공식 명세 작업 그룹**이 구성됨  

- **제약 조건 인코딩의 일관성 부족**  
  - poison 플래그, 메타데이터, 속성, assumes 등 다양한 방식이 혼재  
  - 정보 손실 또는 과도한 유지로 최적화에 부정적 영향  

- **부동소수점(FP) 의미 체계 문제**  
  - **신호 NaN**, **비표준 환경**, **denormal 처리**, **x87 초과 정밀도** 등에서 불일치 발생  
  - 제약된 FP intrinsic으로 별도 처리되어 복잡성 증가  

### 기타 기술적 문제

- **부분적 마이그레이션 지연**  
  - **새 패스 매니저**는 중간단계까지만 적용, 백엔드는 여전히 구형 사용  
  - **GlobalISel**은 10년째 완전 전환되지 못함, SDAG와 병존  

- **ABI 및 호출 규약 처리 혼란**  
  - 프런트엔드와 백엔드 간 책임 분리가 불명확하고 문서화 부족  
  - **ABI 라이브러리** 도입 및 프로토타입 구현이 진행 중  
  - 타깃 기능 활성화에 따라 ABI가 달라지는 문제 존재  

- **빌트인 함수 및 libcalls 관리 불일치**  
  - **TargetLibraryInfo**와 **RuntimeLibcalls**가 분리되어 일관성 부족  
  - 런타임 라이브러리 종류(libgcc, compiler-rt 등)에 따른 가용성 인식 불가  
  - Rust 등 외부 런타임의 커스터마이징 포인트 부재  

- **Context / Module 구조의 비효율성**  
  - 타입·상수가 Context에, 함수·글로벌이 Module에 존재  
  - 데이터 레이아웃 접근 불가로 상수 폴딩 등에서 불편  
  - 교차 컨텍스트 링크 불가, 구조 단순화 필요  

- **LICM(루프 불변 코드 이동)으로 인한 레지스터 압박**  
  - 비용 모델 없이 무조건 hoist 수행  
  - 백엔드에서 다시 sink하지 않아 **스필·리로드 증가**  

### 결론

- 나열된 문제들은 LLVM의 **성숙도와 규모에서 비롯된 구조적 과제**로,  
  **프로젝트 품질과 기여자 경험을 개선할 기회**로 제시됨  
- 일부 영역(빌드 최적화, ABI 라이브러리, 성능 추적 등)은 이미 개선 작업이 진행 중임  
- 전체적으로 LLVM은 여전히 강력하지만, **지속적 리팩터링과 명세 정비가 필수적임**

## Comments



### Comment 49168

- Author: neo
- Created: 2026-01-13T17:32:55+09:00
- Points: 1

###### [Hacker News 의견들](https://news.ycombinator.com/item?id=46588837) 
- 글 전체가 잘 정리되어 있어서 공감이 많이 됨  
  요즘 **LLVM IR의 안정성**이 꽤 높아졌음. Fil-C를 LLVM 17에서 20으로 하루 만에 리베이스했음.  
  다른 프로젝트에서도 여러 LLVM 버전에서 동일한 pass를 유지했는데 큰 문제 없었음  
  다만 **LICM의 레지스터 압박**이 특히 C/C++이 아닌 소스에서 심각함. 문제는 LICM 자체보다 regalloc이 rematerialize를 더 잘 배우도록 해야 하는 부분 같음
  - regalloc은 이미 rematerialize를 알고 있음. 다만 백엔드가 최적화기보다 **지역적 시야**만 가지다 보니 LICM이 만든 나쁜 결정을 되돌리기 어려움
  - rematerialize pass는 이미 존재함. 굳이 register allocation과 묶을 필요는 없음. LLVM regalloc은 원래도 완벽하지 않음  
    프런트엔드 개발자가 다양한 설정을 **벤치마크**해 최적값을 고를 수 있도록 옵션을 더 개방하면 좋겠음
  - 나는 LLVM 전문가가 아니지만, 예전에 다뤄봤을 때 IR은 하나의 언어라기보다 여러 언어의 **공통 어휘집**처럼 느껴졌음.  
    각 도구와 컴포넌트가 자신만의 규칙을 가지고 있어서 버전 간 차이가 생기는 게 오히려 자연스러움. 혹시 내가 잘못 이해한 걸까 하는 궁금증이 있음

- LLVM 18을 macOS에서 빌드하려고 compiler-rt 담당자에게 boolean 하나만 바꿔달라 요청했는데, “heated” 이슈로 잠겨버리고 4년째 미해결 상태임  
  그래도 LLVM은 여전히 사랑함. **clang-tidy, ASAN, UBSAN, LSAN, MSAN, TSAN**은 정말 훌륭함.  
  C/C++ 코드를 작성하면서 clang-tidy를 안 쓰는 건 잘못된 선택이라 생각함  
  다만 -fbounds-safety는 AppleClang에만 있고, MSAN/LSAN은 LLVM Clang에만 있음. Xcode에는 clang-tidy, clang-format, llvm-symbolizer도 없음.  
  결국 macOS에서는 직접 **Darwin LLVM을 빌드**해서 써야 했음.  
  Linux 쪽도 혼란스러움. RHEL은 libcxx를 안 주지만 Fedora는 줌. 그러나 MSAN용으로 instrument된 libcxx는 어떤 배포판에도 없음  
  Fedora가 거의 다 왔지만 여전히 compiler-rt를 수동으로 빌드해야 함
  - Gentoo를 써보라고 권유받음. [Gentoo LLVM 위키](https://wiki.gentoo.org/wiki/LLVM) 참고  
  - Chimera Linux나 Mandriva는 LLVM이 기본적으로 잘 작동하지 않냐는 질문도 있었음. Chimera는 꽤 **LLVM 네이티브**함

- 최근 LLVM 관련 논의들을 겪으며, C가 아닌 **LLVM IR에서 시작하는 실행 가능한 테스트 스위트**가 꼭 필요하다고 느낌  
  백엔드를 직접 만들어보면 SelectionDAG나 GlobalISel 관련 문서가 부족하고, 연산 의미가 불명확해서 잘못 구현하기 쉬움

- **C API**는 LLVM에서 소외된 존재처럼 느껴짐. 많은 옵션이나 opt pass가 노출되어 있지 않음  
  - 이는 LLVM의 **C++ API의 표현력**이 C 스타일 인터페이스로 옮기기 어렵기 때문임.  
    대부분의 개발자가 C++ API를 직접 쓰기 때문에 C API는 후순위로 밀리고, 결국 **2등 시민**으로 남게 됨

- 코드 리뷰가 즉각적인 보상으로 이어지지 않아서 사람들이 잘 안 하게 됨  
  리뷰에도 기여 크레딧을 준다면 동기부여가 생길 것 같음  
  - 회사 내부에서도 비슷한 문제를 겪음. 내 회사는 리뷰의 **품질과 양을 평가 항목**에 넣지만, 여전히 충분한 동기부여가 되지는 않음

- 6년 전 8GB Dell 9360 노트북으로 LLVM을 자주 빌드했음. 링크 병렬성을 줄이면 메모리 한계 내에서 가능했음  
  지금도 8GB로 빌드가 가능한지 궁금함  
  - 병렬 빌드를 끄고 스왑을 몇 GB 확보하면 가능함. 다만 **링커 설정 플래그**를 조정해야 함  
  - M1 Mac에서는 모든 빌드 설정에서 LLVM이 한 시간 이내로 컴파일됨

- LLVM 초창기에는 **GCC보다 빠른 컴파일 속도**가 장점이었음.  
  이제 23년이 지난 LLVM 이후에 또 새로운 것이 나올지 궁금함  
  - 최근 누군가 LLVM의 -O0 백엔드를 10~20배 빠르게 만든 [TPDE 프로젝트](https://discourse.llvm.org/t/tpde-llvm-10-20x-faster-llvm-o0-back-end/86664)가 있었지만 주목받지 못함  
    LLVM IR을 쓰지 않는 **Cranelift** 같은 대안도 있음 ([Cranelift GitHub](https://github.com/bytecodealliance/wasmtime/tree/main/cranelift))  
  - 그래도 LLVM은 C/C++ 컴파일에 매우 뛰어남. 완벽하진 않지만, 비슷한 수준을 만들려면 **수만 인시의 노력**이 필요함

- **ABI와 호출 규약 처리**가 가장 큰 고통임.  
  컴파일러 프런트엔드에서 직접 인자 전달을 관리해야 하고, 때로는 **레지스터 개수 계산**까지 해야 함

- 글에서는 “프런트엔드는 안정적인 C API 덕분에 보호받는다”고 했지만, 실제로는 그렇지 않음  
  일부 API는 안정적이지만 Orc 같은 부분은 자주 바뀜  
  - Orc C API는 다른 C API와 **규칙이 다름** ([Orc.h 소스 링크](https://github.com/llvm/llvm-project/blob/501416a755d1b85ca10507301aac273843a15a39/llvm/include/llvm-c/Orc.h#L20-L23))

- LLVM은 **이슈 리뷰 체계**가 거의 없는 것 같음. 내가 올린 버그 리포트들도 몇 년째 처리되지 않음