Các câu hỏi để biên dịch sang LLVM

Question

Tôi đã chơi xung quanh với LLVM hy vọng tìm hiểu cách sử dụng nó.

Tuy nhiên, tâm trí của tôi bị boggled bởi mức độ phức tạp của giao diện.

Đưa ví dụ chức năng Fibonacci họ

int fib(int x) { 
    if(x<=2) 
     return 1; 
    return fib(x-1) + fib(x-2); 
    } 

Để có được điều này để đầu ra LLVM IR, phải mất 61 dòng mã !!!

Chúng cũng bao gồm BrainFuck được biết là có trình biên dịch nhỏ nhất (200 byte). Thật không may, với LLVM, nó là hơn 600 dòng (18 kb).

Đây có phải là chuẩn cho trình phụ trợ của trình biên dịch không? Cho đến nay nó có vẻ như nó sẽ dễ dàng hơn để làm một hội đồng hoặc phụ trợ C.

Answer 1

Vấn đề nằm ở C++ chứ không phải LLVM.

Sử dụng ngôn ngữ được thiết kế cho lập trình meta, như OCaml và trình biên dịch của bạn sẽ nhỏ hơn rất nhiều. Ví dụ: this OCaml Journal article describes an 87-line LLVM-based Brainfuck compiler, this mailing list post describes complete programming language implementation including parser có thể biên dịch hàm Fibonacci (giữa các chương trình khác) và toàn bộ trình biên dịch dưới 100 dòng mã OCaml sử dụng LLVM và HLVM is a high-level virtual machine with multicore-capable garbage collection in under 2,000 lines of OCaml code using LLVM.

Answer 2

Không LLVM sau đó tối ưu hóa IR tùy thuộc vào kiến ​​trúc cụ thể được triển khai trong back-end? Mã IR không được dịch trực tiếp 1: 1 thành nhị phân cuối cùng. Theo tôi hiểu, đó là cách nó hoạt động. Tuy nhiên, tôi chỉ bắt đầu chơi xung quanh với back-end (tôi đang chuyển nó sang một bộ xử lý tùy chỉnh).

Answer 3

LLVM yêu cầu một số mã soạn sẵn, nhưng một khi bạn hiểu nó, nó thực sự khá đơn giản. Hãy thử tìm kiếm một kết thúc trước GCC đơn giản, và bạn sẽ nhận ra LLVM sạch như thế nào. Tôi chắc chắn sẽ giới thiệu LLVM trên C hoặc ASM. ASM không phải là xách tay chút nào, và việc tạo ra mã nguồn thường là một điều xấu, bởi vì nó làm cho việc biên dịch chậm.

Answer 4

Biểu diễn trung gian có thể hơi dài dòng, so với trình lắp ráp không phải ảo. Tôi đã học được rằng nhìn vào .NET IL, mặc dù tôi không bao giờ đi xa hơn nhiều so với tìm kiếm. Tôi không thực sự quen thuộc với LLVM, nhưng tôi đoán đó là vấn đề tương tự.

Điều này có ý nghĩa khi bạn nghĩ về nó. Một điểm khác biệt lớn là các IR phải đối phó với rất nhiều siêu dữ liệu. Trong assembler có rất ít - bộ xử lý ngầm định nghĩa rất nhiều, và các quy ước cho những thứ như các cuộc gọi hàm được để lại cho trình lập trình/trình biên dịch để xác định. Đó là thuận tiện, nhưng nó tạo ra sự di chuyển lớn và các vấn đề interop.

Trình bày trung gian như .NET và LLVM về đảm bảo rằng các thành phần được biên dịch riêng có thể hoạt động cùng nhau - ngay cả các thành phần được viết bằng các ngôn ngữ khác nhau và được biên dịch bởi các giao diện người biên dịch khác nhau. Điều đó có nghĩa là siêu dữ liệu là cần thiết để mô tả những gì đang diễn ra ở cấp độ cao hơn ví dụ: tùy ý đẩy, bật và tải có thể là xử lý thông số, nhưng có thể là bất cứ thứ gì. Khoản hoàn trả là khá lớn, nhưng có một mức giá phải trả.

Có các vấn đề khác nữa. Các đại diện trung gian không thực sự có nghĩa là để được viết bởi con người, nhưng nó có nghĩa là để có thể đọc được. Ngoài ra, nó có nghĩa là đủ chung để tồn tại một số phiên bản mà không có thiết kế lại hoàn toàn không tương thích từ đầu.

Về cơ bản, trong ngữ cảnh này, rõ ràng là hầu như luôn luôn tốt hơn là ngầm, vì vậy sự khó chịu là khó tránh.