نوع استنتاج

StableHLO در اصل از گویش MHLO بوت استرپ شده بود و اجرای MHLO از نوع استنتاج را به ارث برد. پیشرفت پیاده سازی در status.md ردیابی می شود.

دستورالعمل‌های پیشنهادی زیر برای اطمینان از اجرای تأییدکننده‌های با کیفیت بالا و توابع شکل برای عملیات StableHLO در نظر گرفته شده است.

پیشنهاد

این پیشنهادها هم برای بازبینی پیاده‌سازی‌های موجود و هم برای دستیابی به عملیات‌های جدید تا یک پوشش جامع اعمال می‌شود.

(P1) از مشخصات StableHLO به عنوان منبع حقیقت استفاده کنید

مشخصات منبع حقیقت برای همه تأیید کننده ها و توابع شکل عملیات StableHLO است. تأییدکننده‌های موجود و توابع شکل هر عملیات باید دوباره مورد بازبینی قرار گیرند تا کاملاً با مشخصات هماهنگ شوند. توجه داشته باشید که سند مشخصات همچنان در حال تکامل است. در مواردی که مشخصات یک op در دسترس نیست، پیاده سازی XLA باید به عنوان منبع حقیقت استفاده شود، از جمله xla/service/shape_inference.cc و xla/service/hlo_verifier.cc . پیاده‌سازی XLA پویایی نامحدود را پوشش نمی‌دهد، بنابراین برای پویایی نامحدود، تا زمانی که پویایی RFC در دسترس نباشد، از عقل سلیم استفاده می‌کنیم.

(P2) از ODS نهایت استفاده را ببرید

فایل‌های ODS (مانند StablehloOps.td ) عملیات‌ها را با ویژگی‌ها و انواع برای هر عملوند/ویژگی/نتیجه تعریف می‌کنند و تأیید را انجام می‌دهند. بنابراین هیچ کد تأیید در تأیید کننده ها یا توابع شکل برای ویژگی هایی که قبلاً توسط ODS تضمین شده اند مورد نیاز نیست. اگر کد تأیید با ODS تکراری است، حذف کنید، زیرا هرگز فعال نمی‌شوند.

آیا باید آزمایش هایی را برای محدودیت های ODS اضافه کنیم؟ لطفاً به ایجاد دستورالعمل های تست مراجعه کنید.

(P3) کد تأیید را در تأیید کننده ها و توابع شکل حفظ کنید

هر دو:

• verfiers : پیاده سازی شده توسط Op::verify() و
• توابع شکل : پیاده سازی شده توسط InferTypeOpInterface مانند Op::inferReturnTypes() یا Op::inferReturnTypeComponents

ممکن است کد تأیید برای بررسی عملوندها / ویژگی ها / نتایج داشته باشد. یک تقسیم اولیه ممکن است به صورت زیر باشد: اجازه دهید تائید کننده ها عملوندها/ویژگی ها را بررسی کنند، سپس اجازه دهید توابع شکل فقط انواع نتایج استنتاج شده را محاسبه کنند و سازگاری با انواع نتایج واقعی را بررسی کنند. با این حال، در واقعیت، این تقسیم چند مشکل دارد:

• تابع shape را می توان با توابع build() autogenerated فراخوانی کرد، بدون اینکه ابتدا تایید کننده را فراخوانی کند. بنابراین ورودی های مرتبط باید در تابع shape نیز تایید شوند.
• کد تکراری: به عنوان مثال در تأیید کننده ها، ما برخی از پردازش ها را روی عملوندها انجام می دهیم و سپس برخی از نتایج میانی را تأیید می کنیم. سپس در توابع شکل، این نتایج میانی برای استنتاج نتایج نهایی مفید هستند. این نتایج میانی باید دو بار محاسبه شوند.
• بار تعمیر و نگهداری: تأیید یک عملیات به دو روش مختلف انجام می شود.

راه حل به شرح زیر است:

1. برای اکثر عملیات‌های بدون منطقه (مانند PadOp ): سعی کنید تمام کد تأیید را در توابع شکل قرار دهید و تأییدکننده‌ها را کاملاً کنار بگذارید. در مواردی که به دلیل ناتوانی در استنتاج انواع بازگشت (مانند ReshapeOp یا BroadcastInDimOp )، این امکان وجود ندارد، یک تأییدکننده ایجاد کنید تا منطق تأیید لازم را داشته باشد. عملیات‌های معمولاً قابل استنتاج، مانند AddOp ، ممکن است همچنان برای انجام تأییدیه‌های اضافی به تأییدکننده نیاز داشته باشند، زیرا آنها محدودیت‌های یک نوع بازگشت ارائه شده را تأیید می‌کنند، که در روش‌های استنتاج نوع/شکل قابل دسترسی نیست.

2. برای عملیات‌هایی با مناطق (مانند ReduceOp/IfOp ؛ فهرست کامل در اینجا آمده است): سازنده‌های خود تولید شده، مناطق را به عنوان پارامتر در نظر نمی‌گیرند، بنابراین اگر این سازنده‌ها شامل استنتاج نوع باشند، تابع شکل با مناطق خالی فراخوانی می‌شود ( این مثال را ببینید. ).

   1. اگر مناطق برای استنتاج نوع مورد نیاز نیستند (مانند ReduceOp )، منطق تأیید مربوط به منطقه را به جای توابع شکل در تأییدکننده‌ها قرار دهید. در صورت اجتناب ناپذیر بودن برخی از کدها را کپی کنید.

   2. اگر نواحی برای استنتاج نوع مورد نیاز هستند ( IfOp/CaseOp/MapOp )، سپس تابع شکل باید صریحاً خالی نبودن مناطق را تأیید کند، حتی اگر ODS وجود آن را قبلاً در تعریف Op تضمین کند.

(P4) دستورالعمل های آزمایش را ایجاد کنید

آیا برای تأییدیه هایی که تحت پوشش ODS هستند، نیاز به اضافه کردن/حفظ آزمایشات داریم؟

ما نداریم. آزمایش‌ها باید بر روی تأییدکننده‌ها و توابع شکل تمرکز کنند، در حالی که تغییرات در ODS نیاز به بازبینی این عملیات دارد.

اما مراقب قطعات از دست رفته باشید: برای مثال، اگر عملیات دارای ویژگی SameOperandsAndResultShape باشد که فقط اشکال را بررسی می‌کند اما نوع عنصر را بررسی نمی‌کند، در این صورت تأیید انواع عنصر عملوندها/نتایج هنوز به آزمایش نیاز دارد.

تست های تایید کننده ها و استنتاج نوع را کجا قرار دهیم؟

ops_stablehlo.mlir شامل موارد مثبت ops و (حداقل) 1 تست منفی برای هر خطای تایید است. همچنین می تواند بررسی کند که نوع بازگشتی استنباط شده با نوع نتیجه واقعی (نه مشابه!) سازگار است.

infer_stablehlo.mlir وجود تابع شکل یک op را به خط با hlo_test_infer.get_return_type_components"(%x):... تأیید می کند و بررسی می کند که نوع استنباط شده دقیقاً مطابق انتظار است. به طور کلی یک تست مثبت در هر op.

چه باید کرد

هنگام پیاده سازی یا بازدید مجدد از تابع تایید کننده و/یا شکل یک عملیات:

1. همه موارد مثبت و موارد منفی را در ops_stablehlo.mlir قرار دهید.

2. برای تست رابط، یک تست مثبت در infer_stablehlo.mlir اضافه کنید.

3. (اختیاری) اگر یک عملیات پیچیده است و می‌تواند حاوی آزمایش‌های زیادی باشد، یک فایل آزمایشی جداگانه به نام verify_<op_name>.mlir یا verify_<your_topic>.mlir در همان پوشه اضافه کنید.