이 문서의 내용 중 전체 또는 일부는 넥스32 위키에서 가져왔으며 GNU Free Documentation License 1.3에 따라 이용할 수 있습니다.
본 문서의 원본은 링크에서 확인할 수 있습니다.
본 문서의 원본은 링크에서 확인할 수 있습니다.
| LLVM | |
| 한국어명 | 엘엘브이엠 |
| 기능 | 프로그램 개발도구 |
| 개발 | LLVM 개발자 그룹 |
| 가격 | 자유 |
| 저작권 | BSD |
| 출시 | 2003년 10월 24일 |
| 운영상태 | 운영중 |
| 기반 언어 | Cpp |
| 지원 플랫폼 | 리눅스, FreeBSD(프리BSD), 맥OSX, Mingw32 |
| 주소 | www.llvm.org |
1. 개요 ✎ ⊖
LLVM은 Cpp로 작성된 프로그래밍 언어 컴파일러 및 컴파일 환경 모음으로, 프로그래밍 타겟 플랫폼의 중간단계를 가상화하여 프로그래밍 과정에서 고려해야하는 타겟 플랫폼에대한 복잡한 의존성 문제 및 최적화 문제를 최소화 함으로서 개발자의 편의 도모 및 개발 시간 단축을 위한 프로그래밍을 위한 가상 플랫폼 개념에 해당한다.
LLVM은 원래 저수준 가상 기계(low-level virtual machine)의 약자로 LLVM을 채택했으나, LLVM이 성장하여 다양한 분야에 관련되면서 현재는 이 약자를 공식적으로는 버리고 그냥 LLVM 프로젝트로 불리우고 있다. 컴파일러(compiler), 최적화기(optimizer), JIT 코드생성기(Just-In-Time Code generator)를 비롯한 수많은 컴파일 관련 도구과 라이브러리를 묶어서 개발하고 있다.
기본적으로 LLVM 자체는 프론트 엔드와 백엔드 중간에 위치하는 가상개념의 플랫폼에 해당하는 개념과, 거기서 생성된 중간코드를 다루는 라이브러리 및 툴셋의 묶음이다. 그러나 LLVM프로젝트 자체에서 프론트엔드와 백엔드까지 직접 개발해나가면서 현재는 사실상 종합 컴파일러를 위한 플랫폼의 구현을 위한 프로젝트라고 받아들이면 된다.
가상머신으로서 JIT 형태로 전환된 비트코드를 바로 실행하는 LLI가 있긴하나, 성능면에서는 자바보다도 훨씬 떨어져(구조상 어쩔 수 없음) 테스트 정도는 가능하나 자바 등을 대체하기 위한 기능으로서는 사용하기에 무리가 따른다. 사실상 GCC를 대체할 BSD 라이센스 기반의 크로스 플랫폼 컴파일러로서 받아들여지고 있다고 보면 적합하다.
Chris Lattner이 처음 시작한 프로젝트로, 많은 오픈소스 개발 참여를 통해 개발되어가다가, 애플에서 해당 프로젝트를 회사 차원에서 지원하기 시작하여 개발팀 전체를 고용해 애플의 Xcode의 개발환경을 개선하기 위한 방안으로 개발되어나가고 있다. 유사 BSD라이센스로 배포되어 상업적으로나 비상업적으로나 사용에 제한이 없으며, 이 때문에 FreeBSD(프리BSD)진영을 비롯한 오픈소스 참여자나 구글 등의 기업도 많은 참여를 보이고 있다.
LLVM은 원래 저수준 가상 기계(low-level virtual machine)의 약자로 LLVM을 채택했으나, LLVM이 성장하여 다양한 분야에 관련되면서 현재는 이 약자를 공식적으로는 버리고 그냥 LLVM 프로젝트로 불리우고 있다. 컴파일러(compiler), 최적화기(optimizer), JIT 코드생성기(Just-In-Time Code generator)를 비롯한 수많은 컴파일 관련 도구과 라이브러리를 묶어서 개발하고 있다.
기본적으로 LLVM 자체는 프론트 엔드와 백엔드 중간에 위치하는 가상개념의 플랫폼에 해당하는 개념과, 거기서 생성된 중간코드를 다루는 라이브러리 및 툴셋의 묶음이다. 그러나 LLVM프로젝트 자체에서 프론트엔드와 백엔드까지 직접 개발해나가면서 현재는 사실상 종합 컴파일러를 위한 플랫폼의 구현을 위한 프로젝트라고 받아들이면 된다.
가상머신으로서 JIT 형태로 전환된 비트코드를 바로 실행하는 LLI가 있긴하나, 성능면에서는 자바보다도 훨씬 떨어져(구조상 어쩔 수 없음) 테스트 정도는 가능하나 자바 등을 대체하기 위한 기능으로서는 사용하기에 무리가 따른다. 사실상 GCC를 대체할 BSD 라이센스 기반의 크로스 플랫폼 컴파일러로서 받아들여지고 있다고 보면 적합하다.
Chris Lattner이 처음 시작한 프로젝트로, 많은 오픈소스 개발 참여를 통해 개발되어가다가, 애플에서 해당 프로젝트를 회사 차원에서 지원하기 시작하여 개발팀 전체를 고용해 애플의 Xcode의 개발환경을 개선하기 위한 방안으로 개발되어나가고 있다. 유사 BSD라이센스로 배포되어 상업적으로나 비상업적으로나 사용에 제한이 없으며, 이 때문에 FreeBSD(프리BSD)진영을 비롯한 오픈소스 참여자나 구글 등의 기업도 많은 참여를 보이고 있다.
2. 역사 ✎ ⊖
LLVM 프로젝트는 2000년 일리노이 주 대학에서 Vikram Adve 과 Chris Lattner 두 사람의 주도로 시작되었다. LLVM은 당초 연구 목적으로 시작된 프로젝트로, 최적화를 위한 컴파일러의 중간 단계를 추가한 구조로서, IPO(Interprocedural Optimization) 등을 구현하여 불필요한 요소를 최적화하여 유연하고 빠른 프로그래밍 환경을 만드는 것을 목표로 제작이 시작되었다. 첫 버전은 일리노이 주 대학의 오픈소스 라이센스로 공개되었으며(유사 BSD라이센스), 현재도 그 명맥이 유지되고 있다.
이 개발 플랫폼은 많은 이들에게 주목을 받았으며 높은 참여율을 보였는데, 2005년 애플이 해당 대학의 LLVM 개발자 팀 전원을 자사의 개발팀에 고용, GCC 의존도가 높을 수 밖에 없는 자사의 메인 프로그래밍 언어인 오브젝티브C의 성능 개선및 크로스 플랫폼 이식성을 높여 타 플랫폼에 비해 변동이 심한 자사의 OS X 및 iOS플랫폼 개발에 대응하기 위한 환경 개발에 중심을 두게 된다. (단 애플에 소속된 이후에도 BSD기반의 초기 라이센스를 유지하여 공개하고 있으며, 자사의 프로그래밍 환경은 오브젝티브C 뿐만 아니라 C와 Cpp, 포트란 등 다양한 프론트 엔드를 지원하고 있다)
LLVM 2.0은 애플 산하에서 2007년 처음 선보였으며 성능향상, 다수의 프론트엔드 언어 지원 등의 개선이 이뤄지면서 실질적인 상업적인 활용이 시작되었고, 2011년 말 LLVM 3.0이 나오면서 LLVM으로 특화하지 않은 프로젝트까지 실질적으로 품을 수 있을 수준으로 향상되었다.
그러나 진짜 LLVM이 각광을 받는 대표적 이유 중 하나는, GCC 4.2 이후 GPL 3.0이 적용되어 저작권 관련 문제가 생길 수 있다는 점 때문이다. 성능면에서는 여전히 GCC가 우수하지만 BSD라이센스나 상업라이센스를 사용하는 프로젝트에서 최신 GCC를 사용하기에 곤란함이생기면서 LLVM과 해당 플랫폼의 C컴파일러인 CLang이 급속도로 주목을 받게 되었다.
이 개발 플랫폼은 많은 이들에게 주목을 받았으며 높은 참여율을 보였는데, 2005년 애플이 해당 대학의 LLVM 개발자 팀 전원을 자사의 개발팀에 고용, GCC 의존도가 높을 수 밖에 없는 자사의 메인 프로그래밍 언어인 오브젝티브C의 성능 개선및 크로스 플랫폼 이식성을 높여 타 플랫폼에 비해 변동이 심한 자사의 OS X 및 iOS플랫폼 개발에 대응하기 위한 환경 개발에 중심을 두게 된다. (단 애플에 소속된 이후에도 BSD기반의 초기 라이센스를 유지하여 공개하고 있으며, 자사의 프로그래밍 환경은 오브젝티브C 뿐만 아니라 C와 Cpp, 포트란 등 다양한 프론트 엔드를 지원하고 있다)
LLVM 2.0은 애플 산하에서 2007년 처음 선보였으며 성능향상, 다수의 프론트엔드 언어 지원 등의 개선이 이뤄지면서 실질적인 상업적인 활용이 시작되었고, 2011년 말 LLVM 3.0이 나오면서 LLVM으로 특화하지 않은 프로젝트까지 실질적으로 품을 수 있을 수준으로 향상되었다.
그러나 진짜 LLVM이 각광을 받는 대표적 이유 중 하나는, GCC 4.2 이후 GPL 3.0이 적용되어 저작권 관련 문제가 생길 수 있다는 점 때문이다. 성능면에서는 여전히 GCC가 우수하지만 BSD라이센스나 상업라이센스를 사용하는 프로젝트에서 최신 GCC를 사용하기에 곤란함이생기면서 LLVM과 해당 플랫폼의 C컴파일러인 CLang이 급속도로 주목을 받게 되었다.
3. 특성 ✎ ⊖
LLVM은 GCC와 유사하게 다양한 플랫폼을 지원하는 크로스 플랫폼 프로그래밍 도구이며, 자바, C샵 등과 같은 상위 개념의 가상머신(High-Level Virtual Machine)이 아니라 저레벨의 가상화 하드웨어를 타겟으로 코드를 작성하여 해당 플랫폼에서 작성된 코드를 기반으로 여러 플랫폼으로 이식할 수 있도록 하는 개념을 가진다.
LLVM은 정적/동적 컴파일러와 그와 관련된 여러 도구를 만들고 조작할 수 있는 오픈소스 프로젝트로서, 모듈화된 구조로 인해서 프론트엔드 및 백엔드를 자유자재로 조작할 수 있다는 점은 LLVM의 최대 장점이며, 전체 개발을 Cpp로 통일하여 모듈화가 철저하게 이루어저 개발 시 분석에도 매우 용이하다는 장점이 있다.
일반적인 정적(static) 컴파일러는 프론트엔드(혹은 파서)가 소스코드를 해석해 중간언어(IR, Intermediate Representation)로 만든다. 이 IR은 컴파일러 백엔드(혹은 미들엔드를 두는 컴파일러도 있음)로 보내 각종 최적화를 거친 후 최종적으로 특정 아키텍처의 기계어로 코드를 생성해낸다. 동적 컴파일러 혹은 인터프리터라면 코드 생성기가 인터프리터와 간단한 가상 머신으로 대체된다. 성능 향상을 위해 순수 인터프리터를 쓰기 보다는 JIT를 사용하는 경우도 있다.
LLVM은 자신만의 IR 언어를 정의하고, 이 IR를 조작하고 코드를 생성/수행하는 일을 한다. LLVM 자체는 프런트엔드를 포함하지는 않고 있다. 각 언어의 프론트엔드는 독립적으로 분리되어있다. 즉, C, Cpp, 포트란 등의 LLVM용 프론트엔드 파서가 소스코드를 분석해 LLVM IR로 만들면 비로소 LLVM 프레임웍을 쓸 수 있다.
LLVM IR로 변환된 언어는 플랫폼에서 독립적이며 백엔드를 통해 링킹과정을 통해 기계화 언어로 번역되거나 JIT 형식으로 변환되어 컴파일된다. 즉 LLVM IR로 변환되는 타겟이 바로 특정 하드웨어에 종속되지 않는 독립된 LLVM의 가상화 플랫폼이며, 이 중간과정의 결과물에서 어디로 어떻게 빌드하느냐는 개발자의 선택사항이 된다.
그러나 아직 프로젝트가 진행중인 탓인지 완전하게 플랫폼 독립적인 형태로운영이 되지는 못하고 있다. 소속사에서 주력으로 밀고 있는 맥OS X와 iOS용으로 오브젝티브C 프로젝트를 운용하는 것은 개발에 상당한 중점을 두고 있어 잘돌아가는 듯 하지만, 그 외에는 프로그램이 컴파일은 되는데 프로그램이 돌아가지 않는 등 오류가 적지 않게 보이고 있다. 지속적으로 개선이 되면서 3.02버전에서는 Clang을 이용해서 FreeBSD의 코어가 LLVM기반으로 완전 컴파일 및 작동이 확인되었다.
LLVM은 정적/동적 컴파일러와 그와 관련된 여러 도구를 만들고 조작할 수 있는 오픈소스 프로젝트로서, 모듈화된 구조로 인해서 프론트엔드 및 백엔드를 자유자재로 조작할 수 있다는 점은 LLVM의 최대 장점이며, 전체 개발을 Cpp로 통일하여 모듈화가 철저하게 이루어저 개발 시 분석에도 매우 용이하다는 장점이 있다.
일반적인 정적(static) 컴파일러는 프론트엔드(혹은 파서)가 소스코드를 해석해 중간언어(IR, Intermediate Representation)로 만든다. 이 IR은 컴파일러 백엔드(혹은 미들엔드를 두는 컴파일러도 있음)로 보내 각종 최적화를 거친 후 최종적으로 특정 아키텍처의 기계어로 코드를 생성해낸다. 동적 컴파일러 혹은 인터프리터라면 코드 생성기가 인터프리터와 간단한 가상 머신으로 대체된다. 성능 향상을 위해 순수 인터프리터를 쓰기 보다는 JIT를 사용하는 경우도 있다.
LLVM은 자신만의 IR 언어를 정의하고, 이 IR를 조작하고 코드를 생성/수행하는 일을 한다. LLVM 자체는 프런트엔드를 포함하지는 않고 있다. 각 언어의 프론트엔드는 독립적으로 분리되어있다. 즉, C, Cpp, 포트란 등의 LLVM용 프론트엔드 파서가 소스코드를 분석해 LLVM IR로 만들면 비로소 LLVM 프레임웍을 쓸 수 있다.
LLVM IR로 변환된 언어는 플랫폼에서 독립적이며 백엔드를 통해 링킹과정을 통해 기계화 언어로 번역되거나 JIT 형식으로 변환되어 컴파일된다. 즉 LLVM IR로 변환되는 타겟이 바로 특정 하드웨어에 종속되지 않는 독립된 LLVM의 가상화 플랫폼이며, 이 중간과정의 결과물에서 어디로 어떻게 빌드하느냐는 개발자의 선택사항이 된다.
그러나 아직 프로젝트가 진행중인 탓인지 완전하게 플랫폼 독립적인 형태로운영이 되지는 못하고 있다. 소속사에서 주력으로 밀고 있는 맥OS X와 iOS용으로 오브젝티브C 프로젝트를 운용하는 것은 개발에 상당한 중점을 두고 있어 잘돌아가는 듯 하지만, 그 외에는 프로그램이 컴파일은 되는데 프로그램이 돌아가지 않는 등 오류가 적지 않게 보이고 있다. 지속적으로 개선이 되면서 3.02버전에서는 Clang을 이용해서 FreeBSD의 코어가 LLVM기반으로 완전 컴파일 및 작동이 확인되었다.
4. 프론트엔드 ✎ ⊖
LLVM은 프론트엔드 지원을 늘리면 그만큼 다양한 언어를 사용할 수 있기때문에 다양한 프론트엔드를 지원하며 점차 범위를 넓혀가고 있다.
초기에는 GCC 3.4와 4.0.1에서 빼낸 프론트엔드를 사용하는 C 언어와 Cpp 컴파일러를 지원하고 있으며, 이후에 4.2버전의 GCC 프론트엔드를 지원하고 있다. ADA, C, Cpp, D, 포트란, 오브젝티브C의 프론트엔드를 지원하고 있다.
기본적으로 LLVM이 GCC스택의 코드제네레이터를 대체하기 위해 작성되었기 때문에 LLVM 구조에 맞춰 GCC프론트엔드 또한 많은 수정이 되었다. 그러나 GPL라이센스 문제로 인해 GCC를 중심으로 운용하기 어려워지자 LLVM 자체적인 C언어 프론트엔드인 CLang 프로젝트를 개발해 나가고 있다. 현재 C와 오브젝티브C언어를 지원하고 있으며 제한적인 Cpp지원을 해나가고 있다.
어도비의 액션스크립트나 픽셀벤더, 인텔, AMD 등의 연합에서 밀고있는 OpenCL, 엔비디아의 CUDA나 자바 바이트코드 등도 프론트엔드가 개발되고 있으며, 파이썬, Ruby, PHP, Lua 등의 언어도 프론트엔드가 개발중이다.
그러나 구글에서 새로 개발중인 GOlang의 경우에는 LLVM이 거치는 중간과정이 지나치게 무겁다는 이유로 LLVM용 프론트엔드 프로젝트를 테스트하다가 드롭하기도 했다.
초기에는 GCC 3.4와 4.0.1에서 빼낸 프론트엔드를 사용하는 C 언어와 Cpp 컴파일러를 지원하고 있으며, 이후에 4.2버전의 GCC 프론트엔드를 지원하고 있다. ADA, C, Cpp, D, 포트란, 오브젝티브C의 프론트엔드를 지원하고 있다.
기본적으로 LLVM이 GCC스택의 코드제네레이터를 대체하기 위해 작성되었기 때문에 LLVM 구조에 맞춰 GCC프론트엔드 또한 많은 수정이 되었다. 그러나 GPL라이센스 문제로 인해 GCC를 중심으로 운용하기 어려워지자 LLVM 자체적인 C언어 프론트엔드인 CLang 프로젝트를 개발해 나가고 있다. 현재 C와 오브젝티브C언어를 지원하고 있으며 제한적인 Cpp지원을 해나가고 있다.
어도비의 액션스크립트나 픽셀벤더, 인텔, AMD 등의 연합에서 밀고있는 OpenCL, 엔비디아의 CUDA나 자바 바이트코드 등도 프론트엔드가 개발되고 있으며, 파이썬, Ruby, PHP, Lua 등의 언어도 프론트엔드가 개발중이다.
그러나 구글에서 새로 개발중인 GOlang의 경우에는 LLVM이 거치는 중간과정이 지나치게 무겁다는 이유로 LLVM용 프론트엔드 프로젝트를 테스트하다가 드롭하기도 했다.
