Ban đầu, StableHLO được khởi động từ phương ngữ MHLO và kế thừa cách triển khai MHLO của phương pháp suy luận kiểu dữ liệu. Tiến trình triển khai được theo dõi trong status.md.
Các nguyên tắc được đề xuất dưới đây là nhằm đảm bảo việc triển khai trình xác minh chất lượng cao và định hình các hàm cho hoạt động StableHLO.
Đề xuất
Các đề xuất này áp dụng cho cả việc xem lại các phương thức triển khai hiện có và hoạt động mới cho đến khi triển khai toàn diện.
(P1) Sử dụng thông số kỹ thuật StableHLO làm nguồn đáng tin
spec là nguồn đáng tin cậy cho tất cả trình xác minh và định hình các hàm của hoạt động StableHLO. Bạn cần xem lại các trình xác minh hiện có và định dạng chức năng của mỗi hoạt động để phù hợp hoàn toàn với quy cách. Xin lưu ý rằng tài liệu về quy cách liên tục phát triển. Trong trường hợp không có thông số kỹ thuật cho một op, việc triển khai XLA nên được sử dụng làm nguồn đáng tin cậy, bao gồm xla/service/shape_inference.cc và xla/service/hlo_verifier.cc. Quá trình triển khai XLA không bao gồm tính động không giới hạn, vì vậy, đối với động không giới hạn, chúng tôi sẽ áp dụng thuật toán thông thường cho đến khi có RFC động.
(P2) Khai thác tối đa ODS
Các tệp ODS (như StablehloOps.td) xác định các hoạt động có đặc điểm và loại cho từng toán hạng/thuộc tính/kết quả và sẽ thực hiện việc xác minh. Do đó, bạn KHÔNG cần mã xác minh trong trình xác minh hoặc hàm hình dạng cho các thuộc tính đã được ODS đảm bảo. Xoá mã xác minh nếu mã trùng lặp với ODS, vì các mã này sẽ không bao giờ được kích hoạt.
Chúng tôi có cần thêm kiểm thử cho các quy tắc ràng buộc trong ODS không? Vui lòng xem bài viết Thiết lập nguyên tắc kiểm thử.
(P3) Duy trì mã xác minh trong trình xác minh và định dạng hàm
Cả hai:
- trình xác minh: do
Op::verify()triển khai và - hàm hình dạng: được triển khai bởi các
InferTypeOpInterfacenhưOp::inferReturnTypes()hoặcOp::inferReturnTypeComponents
có thể có mã xác minh để kiểm tra toán hạng/thuộc tính/kết quả. Cách phân tách ban đầu có thể như sau: Cho phép trình xác minh kiểm tra toán hạng/thuộc tính, sau đó cho phép các hàm hình dạng chỉ tính toán loại kết quả suy luận và kiểm tra khả năng tương thích với loại kết quả thực. Tuy nhiên, trên thực tế, việc phân chia này có một vài vấn đề:
- Các hàm
build()được tạo tự động có thể gọi hàm hình dạng mà không cần gọi trình xác minh trước. Vì vậy, các dữ liệu đầu vào có liên quan cũng phải được xác minh trong hàm hình dạng. - Mã trùng lặp: Ví dụ: trong trình xác minh, chúng tôi xử lý một số thao tác rồi xác minh một số kết quả trung gian. Sau đó, trong các hàm có hình dạng, các kết quả trung gian này rất hữu ích cho việc dự đoán kết quả cuối cùng. Những kết quả trung gian này phải được tính toán hai lần.
- Gánh nặng bảo trì: Việc xác minh một hoạt động sẽ diễn ra trong 2 phương thức khác nhau.
Giải pháp như sau:
Đối với hầu hết các hoạt động không có khu vực (như
PadOp): Đặt tất cả mã xác minh vào các hàm hình dạng và loại bỏ hoàn toàn trình xác minh.Đối với hoạt động với khu vực (như
ReduceOp/IfOp; danh sách đầy đủ được trình bày tại đây): Các trình tạo được tạo tự động không lấy vùng làm tham số, vì vậy, nếu các trình tạo này liên quan đến dự đoán kiểu, thì hàm hình dạng sẽ được gọi với các vùng trống (xem ví dụ này).Nếu không cần khu vực cho việc dự đoán kiểu (như
ReduceOp), hãy đặt logic xác minh liên quan đến khu vực vào trình xác minh thay vì các hàm hình dạng. Sao chép một số mã nếu không thể tránh khỏi.Nếu cần khu vực để dự đoán kiểu (
IfOp/CaseOp/MapOp), thì ngoài ra, hàm hình dạng phải xác minh rằng khu vực không trống một cách rõ ràng, mặc dù ODS có thể đã đảm bảo sự tồn tại của khu vực đó trong định nghĩa Op.
(P4) Thiết lập hướng dẫn thử nghiệm
Chúng tôi có cần thêm/duy trì các thử nghiệm cho quá trình xác minh thuộc phạm vi của ODS không?
Chúng tôi thì không. Các bài kiểm thử nên tập trung vào trình xác minh và định hình các hàm, trong khi những thay đổi về ODS cần xem lại hoạt động này.
Tuy nhiên, hãy cẩn thận với những phần bị thiếu: ví dụ: nếu op chứa SameOperandsAndResultShape đặc điểm chỉ kiểm tra hình dạng chứ không kiểm tra loại phần tử, thì việc xác minh các loại phần tử của toán hạng/kết quả vẫn cần được kiểm thử.
Chúng tôi đặt các bài kiểm thử cho trình xác minh và suy luận kiểu dữ liệu ở đâu?
ops_stablehlo.mlir chứa các trường hợp hoạt động dương tính và (ít nhất) 1 kết quả âm tính cho mỗi lỗi xác minh. Bạn cũng có thể kiểm tra để đảm bảo rằng kiểu dữ liệu trả về được dự đoán tương thích với (không giống với kiểu kết quả thực tế).
infer_stablehlo.mlir xác minh sự tồn tại của hàm hình dạng của op theo dòng bằng hlo_test_infer.get_return_type_components"(%x):... và kiểm tra để đảm bảo rằng kiểu suy luận khớp chính xác như dự kiến. Nhìn chung là một lượt kiểm thử dương tính trên mỗi nhóm vận hành.
Việc nên làm
Khi triển khai hoặc truy cập lại trình xác minh và/hoặc định dạng chức năng của một op:
Đặt tất cả các trường hợp dương tính và âm tính vào ops_stablehlo.mlir.
Thêm một kiểm thử dương tính duy nhất vào infer_stablehlo.mlir để kiểm thử giao diện.
(Không bắt buộc) Nếu một op phức tạp và có thể chứa nhiều bài kiểm thử, hãy cân nhắc thêm một tệp kiểm thử riêng có tên
verify_<op_name>.mlirhoặcverify_<your_topic>.mlirtrong cùng một thư mục.