LLVM에 트리 형 IR이 아닌 어셈블리 형 IR이있는 이유는 무엇입니까? 또는 왜 프로젝트가 clang의 AST 대신 LLVM IR을 대상으로합니까?

왜 LLVM의 중간 표현 (LLVM IR)이 트리 형이 아닌 어셈블리 형입니까?

또는 언어 구현이 왜 clang의 AST가 아닌 LLVM IR을 대상으로합니까?

그렇게 보이는 경우 한 번에 두 가지 다른 질문을 시도하지 않습니다. 저에게는 클라이언트와 라이브러리 프로그래머 모두 LLVM의 API가 더 이상 그다지 중요하지 않은 소프트웨어 설계이고 내 질문이 "왜?"라는 의견에 동의 한 것처럼 보입니다.

내가 묻는 이유는 IR이 AST와 같은 경우 LLVM이 프론트 엔드에 더 많은 기능을 제공 할 수있는 것처럼 보이므로 clang의 AST 기반 도구는 모든 프론트 엔드에 사용될 수 있기 때문입니다. 또는 LLVM IR을 대상으로하는 언어가 clang의 AST를 대상으로하면 더 많은 기능을 사용할 수 있습니다.

Clang은 AST를 생성하고 작업하기위한 클래스와 함수를 가지고 있으며 LLVM 프로젝트와 밀접한 관련이있는 유일한 프론트 엔드 프로젝트입니다. 왜 clang의 AST 기능이 LLVM 외부에 있습니까?

내 머리 꼭대기에서 Rust (rustc), D (ldc) 및 Haskell (GHC)은 모두 LLVM을 백엔드로 사용할 수 있지만 Clang AST는 사용하지 않습니다. 잘못). 나는이 컴파일러의 모든 내부 세부 사항을 알지 못하지만 적어도 Rust와 D는 clang의 AST로 컴파일 될 수있는 것처럼 보입니다. 아마도 하스켈도 그럴 수 있지만, 나는 그것에 대해 훨씬 덜 확신합니다.

이것은 역사적 이유 때문입니까 (LLVM은 원래 "낮은 수준의 가상 머신"이며 클랜은 나중에 제공 될 예정입니까)? 다른 프론트 엔드가 LLVM에 공급하는 것을 최대한 많이 제어하기를 원하기 때문입니까? clang의 AST가 "C와 유사하지 않은"언어에 적합하지 않은 근본적인 이유가 있습니까?

나는이 질문이 마음을 읽는 연습이되도록 의도하지 않았다. 컴파일러 디자인에 관심이 있지만 아직 유창하지 않은 사람들에게 도움이되기를 바랍니다. LLVM과 clang 프로젝트는 공개적으로 개발 되었기 때문에,이 프로젝트의 개발에 익숙한 누군가가 대답 할 수 있기를 기대하거나 대답 할만한 자신감이 있다고 생각하는 일부 컴파일 머저리에 대한 대답이 분명하기를 바랍니다.

명백하지만 불만족스러운 답변을 선점하려면 :

예. 어셈블리와 같은 IR을 사용하면 IR을 만드는 사람을보다 효과적으로 제어 할 수 있습니다 (아마도 X lang은 clang보다 코드베이스 및 AST 형식이 더 우수 할 것입니다). 이것이 유일한 대답이라면 질문은 "LLVM 에 어셈블리 만 있는 이유는 무엇입니까? "높은 수준의 트리 같은 IR 대신 낮은 수준의 어셈블리 같은 IR?"

예, 프로그래밍 언어를 AST로 구문 분석하는 것은 어렵지 않습니다 (적어도 다른 컴파일 단계와 비교). 그럼에도 불구하고 왜 별도의 AST를 사용합니까? 다른 것이 없다면 동일한 AST를 사용하면 AST에서 작동하는 도구를 사용할 수 있습니다 (AST 프린터와 같은 단순한 것조차도).

그래, 난 강력하게 더 모듈화되는 것은 좋은 일이라고 동의하지만, 그 유일한 이유라면, 왜 다른 언어 구현 LLVM IR 대신 그 소리의 AST를 대상으로하는 경향이 있습니까?

이러한 선점은 잘못되었거나 세부 사항을 간과 할 수 있으므로 자세한 내용이 있거나 내 가정이 잘못되면 이러한 답변을 자유롭게 제공하십시오.

보다 확실하게 대답 할 수있는 질문에 대답하고 싶은 사람은 조립식 IR과 트리 형 IR의 장점과 단점이 무엇입니까?

여기에는 많은 상호 관련 질문이 있습니다. 가능한 한 최선을 다해 분리하려고 노력할 것입니다.

왜 clang AST가 아닌 LLVM IR에서 다른 언어를 빌드합니까?

이것은 clang이 C / C ++ 프론트 엔드이고 그것이 생성하는 AST가 C / C ++에 밀접하게 결합되어 있기 때문입니다. 다른 언어에서도 사용할 수 있지만 C / C ++의 일부 하위 집합과 거의 동일한 의미가 필요하므로 매우 제한적입니다. 지적했듯이 AST로 구문 분석하는 것은 매우 간단하므로 의미 론적 선택을 제한하는 것이 적은 비용으로 가치가 없을 것 같습니다.

그러나 정적 분석기와 같은 C / C ++ 용 도구를 작성하는 경우 AST를 재사용하면 C / C ++로 작업하는 원시 텍스트보다 AST로 작업하기가 훨씬 쉬워집니다. .

왜 LLVM IR이 그 형태입니까?

LLVM IR은 컴파일러 최적화를 작성하기위한 적절한 형식으로 선택되었습니다. 따라서 주요 특징은 SSA 형식입니다. 그것은 매우 낮은 수준의 IR이므로 광범위한 언어에 적용 할 수 있습니다. 예를 들어, 언어에 따라 많이 다르기 때문에 메모리를 입력하지 않습니다.

이제 컴파일러 최적화 작성은 매우 전문적인 작업이며 종종 언어 기능 디자인과 직교하는 경우가 발생합니다. 그러나 컴파일 된 언어를 빠르게 실행하는 것은 상당히 일반적인 요구 사항입니다. 또한 LLVM IR에서 ASM으로의 변환은 상당히 기계적이며 일반적으로 언어 설계자에게는 흥미롭지 않습니다.

따라서 언어를 LLVM IR로 낮추면 언어 디자이너에게 언어 자체에 집중하도록하는 데 실제로 유용한 "무료"가 많이 제공됩니다.

다른 IR이 도움이 되겠습니까?

물론! AST는 프로그램 구조의 특정 변환에는 적합하지만 프로그램 흐름을 변환하려는 경우 사용하기가 매우 어렵습니다. SSA 양식이 일반적으로 더 좋습니다. 그러나 LLVM IR은 매우 낮은 수준이므로 많은 높은 수준의 구조가 손실됩니다 (의도적으로 더 일반적으로 적용 가능함). AST와 저수준 IR 사이에 IR을 갖는 것이 여기서 유리할 수있다. Rust와 Swift는이 접근 방식을 취하며이 둘 사이에 높은 수준의 IR을 가지고 있습니다.