글 전체가 잘 정리되어 있어서 공감이 많이 됨
요즘 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를 수동으로 빌드해야 함
Hacker News 의견들
글 전체가 잘 정리되어 있어서 공감이 많이 됨
요즘 LLVM IR의 안정성이 꽤 높아졌음. Fil-C를 LLVM 17에서 20으로 하루 만에 리베이스했음.
다른 프로젝트에서도 여러 LLVM 버전에서 동일한 pass를 유지했는데 큰 문제 없었음
다만 LICM의 레지스터 압박이 특히 C/C++이 아닌 소스에서 심각함. 문제는 LICM 자체보다 regalloc이 rematerialize를 더 잘 배우도록 해야 하는 부분 같음
프런트엔드 개발자가 다양한 설정을 벤치마크해 최적값을 고를 수 있도록 옵션을 더 개방하면 좋겠음
각 도구와 컴포넌트가 자신만의 규칙을 가지고 있어서 버전 간 차이가 생기는 게 오히려 자연스러움. 혹시 내가 잘못 이해한 걸까 하는 궁금증이 있음
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를 수동으로 빌드해야 함
최근 LLVM 관련 논의들을 겪으며, C가 아닌 LLVM IR에서 시작하는 실행 가능한 테스트 스위트가 꼭 필요하다고 느낌
백엔드를 직접 만들어보면 SelectionDAG나 GlobalISel 관련 문서가 부족하고, 연산 의미가 불명확해서 잘못 구현하기 쉬움
C API는 LLVM에서 소외된 존재처럼 느껴짐. 많은 옵션이나 opt pass가 노출되어 있지 않음
대부분의 개발자가 C++ API를 직접 쓰기 때문에 C API는 후순위로 밀리고, 결국 2등 시민으로 남게 됨
코드 리뷰가 즉각적인 보상으로 이어지지 않아서 사람들이 잘 안 하게 됨
리뷰에도 기여 크레딧을 준다면 동기부여가 생길 것 같음
6년 전 8GB Dell 9360 노트북으로 LLVM을 자주 빌드했음. 링크 병렬성을 줄이면 메모리 한계 내에서 가능했음
지금도 8GB로 빌드가 가능한지 궁금함
LLVM 초창기에는 GCC보다 빠른 컴파일 속도가 장점이었음.
이제 23년이 지난 LLVM 이후에 또 새로운 것이 나올지 궁금함
LLVM IR을 쓰지 않는 Cranelift 같은 대안도 있음 (Cranelift GitHub)
ABI와 호출 규약 처리가 가장 큰 고통임.
컴파일러 프런트엔드에서 직접 인자 전달을 관리해야 하고, 때로는 레지스터 개수 계산까지 해야 함
글에서는 “프런트엔드는 안정적인 C API 덕분에 보호받는다”고 했지만, 실제로는 그렇지 않음
일부 API는 안정적이지만 Orc 같은 부분은 자주 바뀜
LLVM은 이슈 리뷰 체계가 거의 없는 것 같음. 내가 올린 버그 리포트들도 몇 년째 처리되지 않음