LLVM: 문제점들

• 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은 여전히 강력하지만, 지속적 리팩터링과 명세 정비가 필수적임