Tập 42: Khi C backend bộc lộ giới hạn

Tại sao chúng tôi không thể tiếp tục dùng C làm backend mặc định lâu dài? C chẳng phải rất nhanh, rất portable và có mặt ở mọi nơi đó sao?

Thực tế phát triển trong các Sprint đầu tiên chỉ ra rằng C backend hoạt động giống như một chiếc kính mờ che khuất tầm nhìn của compiler.

Vấn đề thứ nhất là thông báo lỗi (diagnostics). Khi DUY hạ đường (lower) một biểu thức bộ nhớ phức tạp sang C, nếu C compiler phía sau phát hiện lỗi kiểu hoặc lỗi khai báo trong file .c được emit, nó sẽ báo lỗi kèm theo vị trí của file .c đó. Đối với người dùng DUY, việc nhìn thấy một lỗi ở dòng thứ 142 của một file C tạm thời do trình biên dịch tự sinh ra là một sự đánh đố tàn nhẫn. Chúng tôi bị mất hoàn toàn mối liên kết nguồn gốc (source span preservation). Họ gõ lỗi ở file .duy dòng 5, nhưng compiler lại chỉ cho họ lỗi ở file .c dòng 142 với những biến tạm có tên dị dạng như _tmp_var_42.

Vấn đề thứ hai là sự lệch pha về ngữ nghĩa (semantic mismatch). DUY có các khái niệm đặc trưng như region (arena với quy tắc sống nghiêm ngặt) và view (lát cắt bộ nhớ mượn tạm thời). Khi dịch sang C, những khái niệm này bị làm phẳng thành các con trỏ thô (void*) hoặc các struct thô của C. C compiler không hiểu các bất biến (invariants) đó, nên không thể tối ưu hóa dựa trên thông tin đó. Ví dụ, LLVM có thể tận dụng thông tin alias phân tích từ hệ kiểu để thực hiện tối ưu hóa rất mạnh, điều mà C compiler khó lòng suy luận được từ mã C emit thô.

Ngoài ra, ABI mismatch là một cơn ác mộng thường trực. Cách DUY bố trí layout của một tagged union (enum) có payload đôi khi không khớp với cách C compiler tự động căn lề (padding/alignment) struct. Khi gọi chéo giữa các module, chương trình sẽ crash ngầm chỉ vì bên DUY nghĩ byte thứ 4 là tag, còn C compiler nghĩ nó nằm ở byte thứ 8 do căn lề bộ nhớ.

C backend là một cây cầu tạm tuyệt vời để bắt đầu, nhưng nó là một cái trần chặn đứng khả năng hard-lock an toàn và hiệu năng của ngôn ngữ. Để DUY lớn lên, cây cầu này phải được hạ cấp xuống vai trò tham chiếu, nhường chỗ cho LLVM trực tiếp.

---