▲

LLVM: 문제점들

 (npopov.com)
3P by GN⁺ 3일전 | ★ favorite | 댓글 1개
  • 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은 여전히 강력하지만, 지속적 리팩터링과 명세 정비가 필수적임
▲
GN⁺ 3일전  [-]
Hacker News 의견들

  • 글 전체가 잘 정리되어 있어서 공감이 많이 됨
    요즘 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 위키 참고
    • 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 프로젝트가 있었지만 주목받지 못함
      LLVM IR을 쓰지 않는 Cranelift 같은 대안도 있음 (Cranelift GitHub)
    • 그래도 LLVM은 C/C++ 컴파일에 매우 뛰어남. 완벽하진 않지만, 비슷한 수준을 만들려면 수만 인시의 노력이 필요함

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

  • 글에서는 “프런트엔드는 안정적인 C API 덕분에 보호받는다”고 했지만, 실제로는 그렇지 않음
    일부 API는 안정적이지만 Orc 같은 부분은 자주 바뀜

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

답변달기