การอนุมานประเภท

เดิมที StableHLO ใช้เงินลงทุนของตนเองจากภาษาถิ่น MHLO และรับค่ามาจากการนำการอนุมานประเภท MHLO มาใช้ ติดตามความคืบหน้าในการใช้งานใน status.md

หลักเกณฑ์ที่เสนอด้านล่างมีจุดประสงค์เพื่อให้แน่ใจว่ามีการใช้ตัวตรวจสอบคุณภาพสูงและฟังก์ชันการกำหนดรูปร่างสำหรับการดำเนินการ StableHLO

ข้อเสนอ

ข้อเสนอเหล่านี้มีผลกับทั้งการทบทวนการติดตั้งใช้งานที่มีอยู่และการบรรลุเป้าหมายใหม่ๆ จนกว่าจะครอบคลุมทั้งหมด

(P1) ใช้ข้อมูลจำเพาะของ StableHLO เป็นแหล่งข้อมูลที่เชื่อถือได้

specเป็นแหล่งข้อมูลที่เชื่อถือได้สำหรับเครื่องมือตรวจสอบและฟังก์ชันรูปร่างทั้งหมดของ ops StableHLO คุณจะต้องตรวจสอบตัวตรวจสอบที่มีอยู่และฟังก์ชันรูปร่างของทุกการดำเนินการอีกครั้งเพื่อให้สอดคล้องกับข้อกำหนดโดยสมบูรณ์ โปรดทราบว่าเอกสารข้อกำหนดเปลี่ยนแปลงอยู่เสมอ ในกรณีที่ไม่มีข้อมูลจำเพาะสำหรับการดำเนินการ ควรใช้การใช้งาน XLA เป็นแหล่งข้อมูลที่ถูกต้องแทน ซึ่งรวมถึง xla/service/shape_inference.cc และ xla/service/hlo_verifier.cc การนำ XLA ไปใช้นั้นไม่ครอบคลุมไดนามิกที่ไม่มีขอบเขต ดังนั้นเราจะใช้สามัญสำนึกจนกว่า RFC จะรองรับการเปลี่ยนแปลงนี้ได้อย่างอิสระ

(P2) ใช้ ODS ให้เกิดประโยชน์สูงสุด

ไฟล์ ODS (เช่น StablehloOps.td) จะกำหนด Ops ที่มีลักษณะและประเภทสำหรับตัวถูกดำเนินการ/แอตทริบิวต์/ผลลัพธ์แต่ละรายการและจะดำเนินการยืนยัน ดังนั้นจึงไม่จำเป็นต้องใช้รหัสยืนยันในเครื่องมือยืนยันหรือฟังก์ชันรูปร่างสำหรับที่พักที่ ODS รับประกันอยู่แล้ว นำรหัสยืนยันออกหากทำซ้ำกับ ODS เนื่องจากจะไม่มีการทริกเกอร์

เราต้องเพิ่มการทดสอบสำหรับข้อจำกัดจาก ODS ไหม โปรดดูกำหนดหลักเกณฑ์การทดสอบ

(P3) เก็บรักษารหัสยืนยันในเครื่องมือยืนยันและฟังก์ชันรูปร่าง

ทั้ง 2 อย่าง

• เครื่องมือยืนยัน: ติดตั้งใช้งานโดย Op::verify() และ
• ฟังก์ชันรูปร่าง: นำมาใช้โดย InferTypeOpInterface เช่น Op::inferReturnTypes() หรือ Op::inferReturnTypeComponents

อาจมีรหัสยืนยันเพื่อตรวจสอบโอเปอแรนด์/แอตทริบิวต์/ผลลัพธ์ การแยกส่วนเริ่มต้นอาจเป็นดังนี้ ให้ผู้ตรวจสอบตรวจสอบตัวถูกดำเนินการ/แอตทริบิวต์ จากนั้นอนุญาตให้ฟังก์ชันรูปร่างคำนวณเฉพาะประเภทผลลัพธ์ที่อนุมาน และตรวจสอบความเข้ากันได้กับประเภทผลลัพธ์จริง แต่ในความเป็นจริงแล้วการแยกนี้มีปัญหาอยู่ 2-3 ข้อคือ

• ฟังก์ชัน build() ที่สร้างขึ้นโดยอัตโนมัติสามารถเรียกใช้ฟังก์ชันรูปร่างได้โดยไม่ต้องเรียกตัวตรวจสอบก่อน ดังนั้นอินพุตที่เกี่ยวข้องจะต้องได้รับการยืนยัน ในฟังก์ชันรูปร่างด้วย
• โค้ดซ้ำกัน: เช่น ในเครื่องมือยืนยัน เราจะประมวลผลตัวถูกดำเนินการ จากนั้นยืนยันผลลัพธ์ที่อยู่ระหว่างกลาง จากนั้นในรูปร่างฟังก์ชัน ผลลัพธ์ระดับกลางเหล่านี้จะเป็นประโยชน์ในการอนุมานผลลัพธ์สุดท้าย ผลลัพธ์ระดับกลางเหล่านี้ต้องมีการคำนวณ 2 ครั้ง
• ภาระในการบำรุงรักษา: การยืนยันการดำเนินการมี 2 วิธีที่แตกต่างกัน

การแก้ปัญหามีดังนี้

1. สำหรับการดำเนินการส่วนใหญ่ที่ไม่มีภูมิภาค (เช่น PadOp): ลองใส่รหัสยืนยันทั้งหมดลงในฟังก์ชันรูปร่าง และทิ้งตัวตรวจสอบทั้งหมด ในกรณีที่ไม่สามารถทำเช่นนี้ได้เนื่องจากไม่สามารถอนุมานประเภทผลลัพธ์ (เช่น ด้วย ReshapeOp หรือ BroadcastInDimOp) ให้สร้างตัวยืนยันเพื่อให้มีตรรกะการยืนยันที่จำเป็น โดยทั่วไป Ops ที่อนุมานได้ เช่น AddOp อาจจำเป็นต้องมีตัวยืนยันเพื่อดำเนินการยืนยันเพิ่มเติม เนื่องจากเป็นการยืนยันข้อจำกัดของประเภทผลลัพธ์ที่ระบุ ซึ่งเข้าถึงในวิธีการอนุมานประเภท/รูปร่างไม่ได้

2. สำหรับการดำเนินการที่มีเขต (เช่น ReduceOp/IfOp คุณสามารถดูรายการทั้งหมดที่นี่): เครื่องมือสร้างที่สร้างขึ้นโดยอัตโนมัติจะไม่ใช้ภูมิภาคเป็นพารามิเตอร์ ดังนั้นหากเครื่องมือสร้างเหล่านี้เกี่ยวข้องกับการอนุมานประเภท ฟังก์ชันรูปร่างจะถูกเรียกใช้ด้วยพื้นที่ที่ว่างเปล่า (ดูตัวอย่างนี้)

   1. หากไม่จำเป็นต้องใช้ภูมิภาคสำหรับการอนุมานประเภท (เช่น ReduceOp) ให้ใส่ตรรกะการยืนยันที่เกี่ยวข้องกับภูมิภาคในตัวยืนยันแทนฟังก์ชันรูปร่าง ทำซ้ำโค้ดบางอย่างหากหลีกเลี่ยงไม่ได้

   2. หากจำเป็นต้องใช้ภูมิภาคสำหรับการอนุมานประเภท (IfOp/CaseOp/MapOp) นอกจากนี้ ฟังก์ชันรูปร่างจะต้องตรวจสอบว่าภูมิภาคไม่ว่างเปล่าอย่างชัดแจ้ง แม้ว่า ODS อาจรับประกันการมีอยู่ในคำจำกัดความของ Op อยู่แล้ว

(P4) กำหนดหลักเกณฑ์การทดสอบ

เราต้องเพิ่ม/บำรุงรักษาการทดสอบสำหรับการยืนยันที่ครอบคลุมโดย ODS ไหม

เราไม่ทำอย่างนั้น การทดสอบควรมุ่งเน้นที่ตัวตรวจสอบและการกำหนดรูปแบบ ขณะที่การเปลี่ยนแปลง ODS จะต้องทบทวนการทดสอบนี้

แต่โปรดระวังส่วนที่ขาดหายไปด้วย เช่น หาก op มีคุณสมบัติ SameOperandsAndResultShape ซึ่งจะตรวจสอบเฉพาะรูปร่างแต่ไม่ตรวจสอบประเภทองค์ประกอบ ก็ต้องทำการทดสอบยืนยันประเภทของตัวถูกดำเนินการ/ผลลัพธ์ด้วย

เราจะทำการทดสอบตัวยืนยันและพิมพ์การอนุมานจากที่ไหน

ops_stablehlo.mlir มีกรณีของ Ops เป็นบวก และการทดสอบเชิงลบ 1 รายการสำหรับข้อผิดพลาดในการยืนยันทั้งหมด นอกจากนี้ยังตรวจสอบได้ว่าประเภทผลลัพธ์ที่กล่าวถึงใช้ร่วมกันได้กับประเภทผลลัพธ์จริง (ไม่เหมือนกับ!)

infer_stablehlo.mlir จะตรวจสอบการมีอยู่ของฟังก์ชันรูปร่างของ op โดยบรรทัดด้วย hlo_test_infer.get_return_type_components"(%x):... และตรวจสอบว่าประเภทที่อนุมานตรงกันทุกประการอย่างที่คาดไว้ โดยทั่วไป การทดสอบเป็นบวก 1 ครั้งต่อการทดสอบ 1 ทีม

สิ่งที่ต้องทำ

เมื่อใช้หรือกลับไปตรวจสอบฟังก์ชันเครื่องมือยืนยันและ/หรือกำหนดรูปร่างของการดำเนินการ

1. ใส่เคสที่เป็นบวกและเคสเชิงลบทั้งหมดไว้ใน ops_stablehlo.mlir

2. เพิ่มการทดสอบผลบวกรายการเดียวใน infer_stablehlo.mlir เพื่อทดสอบอินเทอร์เฟซ

3. (ไม่บังคับ) หากการดำเนินการมีความซับซ้อนและอาจมีการทดสอบจำนวนมาก ให้พิจารณาเพิ่มไฟล์ทดสอบแยกต่างหากที่ชื่อว่า verify_<op_name>.mlir หรือ verify_<your_topic>.mlir ในโฟลเดอร์เดียวกัน