QBE - Backend trình biên dịch: phiên bản 1.3

 (c9x.me)
1 điểm bởi GN⁺ 4 giờ trước | 1 bình luận | Chia sẻ qua WhatsApp
  • Tối ưu hiệu năng đã được bổ sung đáng kể, giúp QBE 1.3 đạt hơn 63% hiệu năng của trình biên dịch thương mại trên coremark bản gốc, và cải thiện 33% trên bộ kiểm thử Hare so với qbe-1.2
  • QBE 1.3 là bản phát hành lớn nhất kể từ 1.0, bao gồm khoảng 7k dòng được thêm và 1.5k dòng bị xóa
  • Các tối ưu mới bao gồm GVN/GCM, tối ưu vòng lặp, loại bỏ if, đơn giản hóa CFG, v.v., nhưng chỉ giữ lại một số pass đã được kiểm chứng
  • Inlining bị loại khỏi đợt tối ưu này vì có vấn đề không phù hợp với mô hình biên dịch streaming theo đơn vị hàm của QBE
  • Trong biến thể coremark có ee_isdigit được inline và crcu8 được đổi sang cách triển khai đơn giản hơn, không phân nhánh, QBE đã đạt 70% hiệu năng mục tiêu so với gcc -O2
  • Công cụ OCaml mới mgen biên dịch các mẫu IL kiểu lispy thành mã khớp C, cho phép thay thế hoặc đơn giản hóa logic chọn lệnh được viết thủ công trước đây
  • mgen tìm các mẫu IL trong các khối chú thích đặc biệt và chèn mã C ngay bên dưới; ví dụ sử dụng hiện tại có trong isel.c
  • Việc khớp DAG lệnh theo cách đánh số tương tự phương pháp của trình biên dịch Plan9 C của Ken Thompson, đồng thời cũng tạo ra một bộ khớp bytecode đơn giản được runmatch() diễn giải
  • Đã bổ sung hỗ trợ Windows ABI, nên có thể biên dịch cho đích Windows bằng cách truyền -t amd64_win
  • Assembly do QBE tạo ra vẫn dùng cú pháp AT&T, và được khuyến nghị biên dịch bằng assembler mingw
  • Hỗ trợ mã độc lập vị trí đã được cải thiện, cho phép liên kết với shared object mượt hơn trên hầu hết mục tiêu và tạo shared object
  • Cờ hằng động extern mới (DYNCONST) cho phép biểu diễn ở mức IL việc truy cập gián tiếp đến các symbol toàn cục như biến trong thư viện động

Bài viết liên quan

1 bình luận

 
GN⁺ 4 giờ trước
Ý kiến trên Lobste.rs

  • Tôi đang làm một HĐH nhỏ kiểu TRIPOS/Amiga Exec như một dự án sở thích đã kéo dài rất lâu
    Không có bảo vệ bộ nhớ, dùng ánh xạ bộ nhớ phẳng, và việc truyền thông điệp cũng chỉ ở mức chuyển con trỏ
    Nếu muốn tự-hosting cho kiểu hệ thống này thì một trình biên dịch nhỏ có thể tạo PIE/PIC sẽ tiện hơn rất nhiều. Thư viện kiểu Amiga dĩ nhiên phải là PIC, và cũng hay ở chỗ khi đặt tệp thực thi vào đâu đó trong ánh xạ bộ nhớ chia sẻ thì không cần quá nhiều vá lỗi lúc nạp
    GCC và Clang thì làm được nhưng quá đồ sộ. Lần cuối tôi kiểm tra thì TCC chưa làm được PIC, nên chắc tôi sẽ tìm hiểu QBE kỹ hơn

    • Trình biên dịch C của tôi có thể tạo PIC, có thể bạn sẽ quan tâm: https://codeberg.org/lsof/antcc/
      Mong là nghe không giống tự quảng bá. Tôi thực sự rất thích mảng trình biên dịch nhỏ, và nó cũng cần thêm nhiều thử nghiệm
    • Tôi cũng đang làm Ashet OS, một HĐH có ánh xạ bộ nhớ phẳng, mọi thứ đều là PIE, và system call chính là function call
      Nó đã tiến khá xa và hỗ trợ nhiều nền tảng
      Có lẽ sẽ còn lâu mới tự-hosting được. Cần sinh mã Thumb-2, mà thực tế cách duy nhất để làm điều đó là tự viết trình biên dịch. Ngoài mã kernel ra thì chỉ còn 8MB RAM khả dụng
      Nó dùng định dạng tệp thực thi riêng .ashex, được tạo bằng cách chuyển đổi từ tệp ELF. Trong quá trình này, nó tiêu thụ một section đặc biệt về cơ bản chỉ chứa một lệnh nhảy tuyệt đối, rồi app loader sẽ ghi lại thành địa chỉ system call thực tế
      Cái khó của hệ thống bộ nhớ phẳng là hỗ trợ shared object một cách gọn gàng. Nếu muốn chia sẻ mã giữa các ứng dụng khác nhau thì cần hỗ trợ từ trình biên dịch để mọi truy cập dynamic symbol đều đi qua các biến được giữ trong thanh ghi

  • Tôi rất vui vì cuối cùng đã có từ khóa extern mới
    Dù không có trong ghi chú phát hành, nó còn hoạt động cùng với thread, cho phép initial-exec TLS. Điều này cần thiết khi truy cập các biến toàn cục cục bộ theo luồng được định nghĩa trong shared library khác, và FreeBSD cần nó cho ctype.h
    extern cũng cần để truy cập các biến toàn cục thông thường trong shared library trên những nền tảng như macOS hay Haiku, ví dụ stderr. Giờ đây các trình biên dịch dựa trên QBE có thể hỗ trợ nhiều hệ điều hành và trường hợp sử dụng hơn rất nhiều
    Tôi cũng rất biết ơn những cải thiện hiệu năng của Roland. Công việc thật sự xuất sắc

  • Nếu tôi hiểu đúng thì đây là hỗ trợ Windows chính thức à?
    Đây chẳng phải là một trong những hạn chế lớn mang tính lịch sử và vẫn còn tồn tại của QBE sao? Thật tuyệt khi thấy điều này

  • Mục tiêu của dự án này có chồng lấn với Cranelift không? Tôi không thật sự hình dung được khi nào nên dùng QBE

    • QBE gần giống “OpenBSD” của thế giới backend trình biên dịch. Triết lý của nó là sự đơn giản và tối giản, và theo mô tả chính thức, mục tiêu là “mang lại 70% hiệu năng của các trình biên dịch tối ưu hóa công nghiệp với 10% lượng mã”
      Đối thủ cạnh tranh thực tế là Cranelift và LLVM
      Đáng tiếc là trước đây nó chủ yếu được dùng trong các ngôn ngữ hoặc triển khai trình biên dịch mang tính sở thích. Ví dụ myrddin, từng trông như một ngôn ngữ họ C mới, giờ có vẻ đã chết; còn cproc vẫn là một triển khai trình biên dịch C mang tính sở thích còn sống
      Dù vậy, từ khi Hare chọn QBE thì đã có thêm hy vọng. Câu trả lời cho câu hỏi này nằm ở đây: https://harelang.org/documentation/faq.html#why-qbe-instead-of-llvm
    • Tôi nghĩ không chỉ chồng lấn với Cranelift mà còn với cả LLVM
      Tôi không biết đủ sâu để nói chi tiết, nhưng có khá nhiều tài liệu so sánh. Trong phạm vi tôi biết thì QBE hướng tới một backend đơn giản hơn rất nhiều so với hai cái kia

  • Cách dùng một DSL nhỏ để sinh bộ khớp chọn lệnh thật sự rất ngầu