LLVM, 코드 검토부터 성능 추적까지, 개발자가 짚어본 문제점

LLVM은 기여자가 많지만, 코드 검토(Code Review)를 수행할 인력이 부족하여 PR(Pull Request) 지연 및 코드 품질 저하를 야기한다. 특히, 새로운 기여자는 검토자를 찾는 데 어려움을 겪고, 적절한 검토 없이 PR이 머지(Merge)되는 경우가 발생한다. 저자는 Rust의 PR 할당 시스템과 같은 개선 방안을 제시하며, 이는 LLVM의 기여 경험(Contributor Experience)을 향상시키는 데 기여할 수 있다.

LLVM C++ API와 IR(Intermediate Representation)의 잦은 변경은 사용자, 특히 백엔드 개발자에게 큰 부담을 준다. 프론트엔드는 C API를 통해 어느 정도 보호받지만, 백엔드는 API 변경에 직접적으로 대응해야 한다. 저자는 LLVM의 개발 철학인 'upstream or GTFO'를 언급하며, API 안정성 확보의 어려움을 강조한다. 이는 LLVM의 지속적인 발전(Continuous Improvement)과 사용자 편의성 사이의 트레이드오프(Trade-off)를 보여준다.

LLVM은 대규모 프로젝트이므로 빌드 시간이 길고, 디버그 정보 포함 시 더욱 심각해진다. 저자는 프리컴파일 헤더(Pre-compiled Headers) 사용 및 dylib 빌드 방식을 통해 빌드 시간 단축을 제안한다. 또한, CI 환경의 플래키 테스트(Flaky Tests) 및 빌드봇 문제로 인해 실제 오류를 놓치는 경우가 발생한다. 이러한 문제는 개발자의 생산성을 저해하며, CI 시스템의 신뢰도를 떨어뜨린다.

LLVM은 개별 최적화에 대한 테스트는 충분하지만, 전체 최적화 파이프라인에 대한 end-to-end 테스트가 부족하다. 특히, llvm-test-suite의 테스트 범위가 제한적이며, 다양한 데이터 타입 및 연산에 대한 테스트가 미흡하다. 또한, LLVM은 공식적인 성능 추적(Performance Tracking) 인프라가 없어 기여자가 변경 사항의 성능 영향을 평가하기 어렵다. 이러한 문제는 코드 품질 관리 및 성능 개선을 어렵게 만든다.

LLVM의 IR 설계는 undef 값(Undef Values)의 다중 사용 문제 및 추론의 어려움으로 인해 최적화 복잡성을 증가시킨다. 또한, ABI 처리와 관련하여 프론트엔드와 백엔드 간의 계약 문서화 부족 및 타겟 기능(Target Features)과 ABI 간의 비직교성(Non-orthogonality) 문제가 존재한다. 이러한 문제는 컴파일러의 정확성 및 성능에 영향을 미치며, LLVM의 유지보수성을 저해한다.

LLVM은 대규모 프로젝트이므로, 새로운 기능 도입 시 부분적인 마이그레이션이 장기간에 걸쳐 진행된다. 특히, 새로운 패스 매니저(Pass Manager) 및 GlobalISel의 완전한 도입이 지연되고 있다. 또한, LLVM은 컴파일 시간이 길어 JIT 사용 사례 및 대량의 IR을 생성하는 경우에 문제가 발생한다. 저자는 -O0 컴파일 시간 개선의 필요성을 강조하며, LLVM의 전반적인 컴파일 성능(Overall Compilation Performance) 향상을 위한 노력을 촉구한다.