הסקת מסקנות

האתחול של StableHLO בוצע במקור מדיאלקט ה-MHLO, והוא ירש את ההטמעה של ה-MHLO של הסקת סוג. מתבצע מעקב אחרי התקדמות ההטמעה ב-status.md.

ההנחיות הבאות נועדו להבטיח הטמעה של מאמתים באיכות גבוהה ופונקציות עיצוב לפעולות StableHLO.

הצעה

ההצעות האלה רלוונטיות גם לחזרה להטמעות קיימות וגם להשגת פעולות חדשות, עד לקבלת כיסוי מקיף.

(P1) שימוש במפרט של StableHLO כמקור מידע אמין

ה-spec הם מקור האמת לכל המאמתים ופונקציות הצורה של פעולות StableHLO. צריך לבדוק שוב את המאמתים הקיימים ואת פונקציות הצורה של כל פעולה כדי שיתאימו באופן מלא למפרט. שימו לב שמסמך המפרט ממשיך להתפתח. במקרים שבהם אין מפרט זמין לפעולה, יש להשתמש בהטמעה של XLA כמקור האמת, כולל xla/service/shape_inference.cc ו-xla/service/hlo_verifier.cc. הטמעת XLA לא כוללת דינמיזם מלא, ולכן בדינמיקה בלתי מוגבלת נשתמש בהיגיון פשוט עד שה-RFC יהיה זמין.

(P2) להפיק את המרב מ-ODS

קובצי ODS (כמו StablehloOps.td) מגדירים פעולות עם תכונות וסוגים לכל אופרנד/מאפיין/תוצאה, ויבצעו את האימות. לכן לא נדרש קוד אימות במאמתים או בפונקציות הצורה לנכסים שכבר מובטחים על ידי ה-ODS. מסירים את קוד האימות אם הוא משוכפל עם ODS, כי הוא אף פעם לא יופעל.

האם צריך להוסיף בדיקות למגבלות מ-ODS? למידע נוסף, ראו קביעת הנחיות לבדיקה.

(P3) שמירה על קוד האימות במאמתים ובפונקציות צורה

שני הסוגים:

• מאמתים: מיושמים על ידי Op::verify() וגם
• פונקציות צורה: מוטמעות על ידי InferTypeOpInterface, למשל Op::inferReturnTypes() או Op::inferReturnTypeComponents

עשוי לכלול קוד אימות לבדיקת אופרנדים/מאפיינים/תוצאות. החלוקה הראשונית עשויה להיות: מאפשרים למאמתים לבדוק את האופרנדים או המאפיינים, ואז לאפשר לפונקציות צורה לחשב רק את סוגי התוצאות שהוסקו, ולבדוק את התאימות לסוגי התוצאות האמיתיות. עם זאת, במציאות יש לפיצול הזה כמה בעיות:

• הפונקציות build() שנוצרות באופן אוטומטי יכולות לקרוא לפונקציית הצורה, בלי להפעיל קודם את המאמת. כך שיש לאמת גם את ערכי הקלט הקשורים בפונקציית הצורה.
• קוד כפול: לדוגמה, במאמתים אנחנו מבצעים עיבוד מסוים באופרנדים ולאחר מכן מאמתים תוצאות ביניים. לאחר מכן, בפונקציות הצורה, תוצאות הביניים האלה מועילות לצורך הסקת התוצאות הסופיות. צריך לחשב את תוצאות הביניים האלה פעמיים.
• נטל תחזוקה: אימותים של פעולה נכללים בשתי שיטות שונות.

הפתרון הוא:

1. לרוב הפעולות ללא אזורים (כמו PadOp): כדאי לנסות להציב את כל קוד האימות בפונקציות הצורה, ולמחוק את המאמתים לגמרי. במקרים שבהם זה לא אפשרי בגלל שאין לכם אפשרות להסיק את סוגי ההחזרות (כמו ReshapeOp או BroadcastInDimOp), כדאי ליצור מאמת שכולל את לוגיקת האימות הדרושה. יכול להיות שפעולות שניתן להסיק בדרך כלל, כמו AddOp, עדיין יצטרכו מאמת כדי לבצע אימותים נוספים, כי הם מאמתים אילוצים של סוג החזרה נתון, שאי אפשר לגשת אליו בשיטות ההסקה של סוג/צורה.

2. לפעולות תפעול עם אזורים (כמו ReduceOp/IfOp; הרשימה המלאה מופיעה כאן): ה-builders שנוצרו באופן אוטומטי לא לוקחים את האזורים כפרמטרים, כך שאם ה-builders האלה כוללים הסקת סוג, פונקציית הצורה תיקרא עם אזורים ריקים (ראו דוגמה זו).

   1. אם האזורים לא נחוצים לצורך הסקת סוג (כמו ReduceOp), צריך להציב את לוגיקת האימות שקשור לאזורים במאמתים במקום בפונקציות הצורה. שכפל חלק מהקוד אם זה בלתי נמנע.

   2. אם האזורים נחוצים לצורך הסקת סוג (IfOp/CaseOp/MapOp), בנוסף, פונקציית הצורה צריכה לוודא שהאזורים לא ריקים במפורש, למרות שה-ODS כבר יכול להבטיח את קיומו בהגדרת התפעול.

(P4) לקבוע הנחיות לבדיקה

האם צריך להוסיף או לתחזק בדיקות אימות שמתבצעות בכפוף ל-ODS?

אנחנו לא עושים זאת. הבדיקות צריכות להתמקד במאמתים ובפונקציות הצורה, בעוד ששינויים ב-ODS מחייבים בדיקה חוזרת של הפעולה הזו.

אבל כדאי לשים לב לחלקים החסרים: לדוגמה, אם הפעולה מכילה את התכונה SameOperandsAndResultShape, שבודקת רק צורות ולא את סוג הרכיב, עדיין צריך לבצע בדיקות לאימות של סוגי הרכיבים של אופרנדים/תוצאות.

איפה עורכים בדיקות של מאמתים ומהי הסקות?

ops_stablehlo.mlir מכיל את המקרים החיוביים של פעולות, ולפחות בדיקה שלילית אחת לכל שגיאת אימות. תוכלו גם לבדוק שסוג ההחזרה המשוער תואם (לא זהה!) לסוג התוצאה האמיתית.

infer_stablehlo.mlir מאמת את הקיום של פונקציית הצורה של פעולה אחרת בשורה עם hlo_test_infer.get_return_type_components"(%x):... ובודק שהסוג שהופק תואם בדיוק כמצופה. בדיקה חיובית אחת לכל פעולה באופן כללי.

מה לעשות

כשמטמיעים את כלי המאמת ו/או את פונקציית הצורה של פעולה, או נכנסים אליהם מחדש:

1. צריך לציין את כל המקרים החיוביים והמקרים השליליים ב-ops_stablehlo.mlir.

2. מוסיפים בדיקה חיובית אחת ב-infer_stablehlo.mlir כדי לבדוק את הממשק.

3. (אופציונלי) אם פעולה מורכבת יכולה להכיל הרבה בדיקות, כדאי להוסיף קובץ בדיקה נפרד בשם verify_<op_name>.mlir או verify_<your_topic>.mlir בתוך אותה תיקייה.