סוג ההשערה

מערכת האתחול של 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): צריך להזין את כל קוד האימות בפונקציות של הצורה ולמחוק לגמרי את המאמתים.

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

   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 באותה תיקייה.