استنتاج النوع

تم بدء تشغيل 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 قد يضمن وجودها في تعريف Op.

(مستوى الأولوية 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 ضِمن المجلد نفسه.