টাইপ ইনফারেন্স

StableHLO মূলত MHLO উপভাষা থেকে বুটস্ট্র্যাপ করা হয়েছিল, এবং এটি টাইপ ইনফারেন্সের MHLO বাস্তবায়ন উত্তরাধিকারসূত্রে পেয়েছে। বাস্তবায়ন অগ্রগতি status.md এ ট্র্যাক করা হয়।

নীচের প্রস্তাবিত নির্দেশিকাগুলি StableHLO অপারেশনগুলির জন্য উচ্চ-মানের যাচাইকরণ এবং আকার ফাংশনগুলির বাস্তবায়ন নিশ্চিত করার উদ্দেশ্যে।

প্রস্তাব

এই প্রস্তাবগুলি বিদ্যমান বাস্তবায়নের পুনর্বিবেচনা, এবং একটি ব্যাপক কভারেজ না হওয়া পর্যন্ত নতুন অপারেশনগুলি অর্জন উভয়ের ক্ষেত্রেই প্রযোজ্য।

(P1) সত্যের উৎস হিসেবে StableHLO স্পেক ব্যবহার করুন

StableHLO ops-এর সমস্ত যাচাইকারী এবং আকৃতি ফাংশনের জন্য স্পেক সত্যের উৎস। স্পেসিফিকেশনের সাথে সম্পূর্ণভাবে সারিবদ্ধ হতে প্রতিটি অপের বিদ্যমান ভেরিফায়ার এবং শেপ ফাংশনগুলিকে পুনর্বিবেচনা করতে হবে। উল্লেখ্য যে স্পেসিফিকেশন ডকুমেন্ট বিকশিত হতে থাকে। যে ক্ষেত্রে একটি অপের জন্য স্পেক উপলব্ধ নেই, XLA বাস্তবায়নকে সত্যের উৎস হিসাবে ব্যবহার করা উচিত, এর পরিবর্তে xla/service/shape_inference.cc এবং xla/service/hlo_verifier.cc । XLA বাস্তবায়ন সীমাহীন গতিশীলতাকে কভার করে না, তাই সীমাহীন গতিশীলতার জন্য আমরা গতিশীলতা RFC উপলব্ধ না হওয়া পর্যন্ত সাধারণ জ্ঞান প্রয়োগ করব।

(P2) ODS-এর সর্বোচ্চ ব্যবহার করুন

ODS ফাইলগুলি (যেমন StablehloOps.td ) প্রতিটি অপারেন্ড/অ্যাট্রিবিউট/ফলাফলের জন্য বৈশিষ্ট্য এবং প্রকারের সাথে অপস সংজ্ঞায়িত করে এবং যাচাইকরণ করবে। এইভাবে ওডিএস দ্বারা ইতিমধ্যে গ্যারান্টিযুক্ত বৈশিষ্ট্যগুলির জন্য যাচাইকারী বা আকৃতি ফাংশনে কোনও যাচাইকরণ কোডের প্রয়োজন নেই। ODS এর সাথে ডুপ্লিকেট করা হলে যাচাইকরণ কোডটি সরান, কারণ সেগুলি কখনই ট্রিগার হবে না।

আমাদের কি ODS থেকে সীমাবদ্ধতার জন্য পরীক্ষা যোগ করতে হবে? অনুগ্রহ করে পরীক্ষা নির্দেশিকা স্থাপন দেখুন।

(P3) যাচাইকারী এবং আকৃতি ফাংশনে যাচাইকরণ কোড বজায় রাখুন

উভয়:

• যাচাইকারী : Op::verify() , এবং দ্বারা প্রয়োগ করা হয়েছে
• শেপ ফাংশন : Op::inferReturnTypes() বা Op::inferReturnTypeComponents এর মত InferTypeOpInterface দ্বারা বাস্তবায়িত

অপারেন্ড/অ্যাট্রিবিউট/ফলাফল পরীক্ষা করার জন্য যাচাইকরণ কোড থাকতে পারে। একটি প্রাথমিক বিভাজন নিম্নরূপ হতে পারে: যাচাইকারীকে অপারেন্ড/অ্যাট্রিবিউটগুলি পরীক্ষা করতে দিন, তারপর আকৃতি ফাংশনগুলিকে শুধুমাত্র অনুমিত ফলাফলের প্রকারগুলি গণনা করতে দিন এবং প্রকৃত ফলাফলের প্রকারগুলির সাথে সামঞ্জস্যতা পরীক্ষা করুন৷ যাইহোক, বাস্তবে এই বিভাজনের কয়েকটি সমস্যা রয়েছে:

• শেপ ফাংশনটি অটোজেনারেটেড build() ফাংশন দ্বারা কল করা যেতে পারে, প্রথমে যাচাইকারীকে কল না করে। তাই আকৃতি ফাংশনেও সংশ্লিষ্ট ইনপুটগুলিকে অবশ্যই যাচাই করতে হবে।
• ডুপ্লিকেটেড কোড: উদাহরণ স্বরূপ ভেরিফায়ারে আমরা অপারেন্ডে কিছু প্রক্রিয়াকরণ করি এবং তারপর কিছু মধ্যবর্তী ফলাফল যাচাই করি। তারপর আকৃতি ফাংশনে এই মধ্যবর্তী ফলাফল চূড়ান্ত ফলাফল অনুমান করার জন্য দরকারী। এই মধ্যবর্তী ফলাফলগুলি দুবার গণনা করতে হবে।
• রক্ষণাবেক্ষণের বোঝা: একটি অপের যাচাইকরণ দুটি ভিন্ন পদ্ধতিতে রয়েছে।

সমাধান নিম্নরূপ:

1. অঞ্চল ছাড়া বেশিরভাগ অপারেশনের জন্য (যেমন PadOp ): সমস্ত যাচাইকরণ কোড শেপ ফাংশনে রাখার চেষ্টা করুন এবং ভেরিফায়ার সম্পূর্ণভাবে বাতিল করুন। যে ক্ষেত্রে রিটার্নের ধরন অনুমান করতে অক্ষমতার কারণে এটি সম্ভব নয় (যেমন ReshapeOp বা BroadcastInDimOp এর সাথে), প্রয়োজনীয় যাচাইকরণ যুক্তি ধারণ করার জন্য একটি যাচাইকারী তৈরি করুন৷ সাধারণত অনুমানযোগ্য অপ্স, যেমন AddOp , অতিরিক্ত যাচাইকরণের জন্য এখনও একটি যাচাইকারীর প্রয়োজন হতে পারে, কারণ তারা একটি প্রদত্ত রিটার্ন প্রকারের সীমাবদ্ধতা যাচাই করছে, যা প্রকার/আকৃতির অনুমান পদ্ধতিতে অ্যাক্সেসযোগ্য নয়।

2. অঞ্চলগুলির সাথে অপারেশনগুলির জন্য (যেমন ReduceOp/IfOp ; একটি সম্পূর্ণ তালিকা এখানে রয়েছে): স্বয়ংক্রিয়ভাবে তৈরি বিল্ডাররা অঞ্চলগুলিকে প্যারামিটার হিসাবে নেয় না, তাই যদি এই নির্মাতারা টাইপ ইনফারেন্স জড়িত থাকে, তাহলে আকৃতি ফাংশনটি খালি অঞ্চলগুলির সাথে কল করা হবে ( এই উদাহরণটি দেখুন) )

   1. যদি টাইপ ইনফারেন্সের জন্য অঞ্চলগুলির প্রয়োজন না হয় (যেমন ReduceOp ), শেপ ফাংশনের পরিবর্তে ভেরিফায়ারে অঞ্চল সম্পর্কিত যাচাইকরণ যুক্তি রাখুন। কিছু কোড নকল করুন যদি এটি অনিবার্য হয়।

   2. যদি টাইপ ইনফারেন্সের জন্য অঞ্চলগুলির প্রয়োজন হয় ( IfOp/CaseOp/MapOp ), তবে অতিরিক্ত আকার ফাংশনটি অবশ্যই যাচাই করতে হবে যে অঞ্চলগুলি স্পষ্টভাবে খালি নয়, যদিও ODS ইতিমধ্যে Op সংজ্ঞায় এর অস্তিত্বের নিশ্চয়তা দিতে পারে।

(P4) পরীক্ষার নির্দেশিকা স্থাপন করুন

ওডিএস দ্বারা আচ্ছাদিত যাচাইকরণের জন্য আমাদের কি পরীক্ষা যোগ/রক্ষণাবেক্ষণ করতে হবে?

আমরা করিনা. পরীক্ষাগুলি যাচাইকারী এবং আকৃতির ফাংশনগুলির উপর ফোকাস করা উচিত, যখন ODS-তে পরিবর্তনের জন্য এই অপারেটিং সিস্টেমটি পুনরায় দেখার প্রয়োজন।

কিন্তু অনুপস্থিত অংশগুলি সম্পর্কে সতর্ক থাকুন: উদাহরণস্বরূপ, যদি op-এ SameOperandsAndResultShape বৈশিষ্ট্যটি থাকে, যা শুধুমাত্র আকারগুলি পরীক্ষা করে কিন্তু উপাদানের প্রকার নয়, তাহলে উপাদানের প্রকারের অপারেন্ড/ফলাফলগুলির জন্য যাচাইকরণের এখনও পরীক্ষা প্রয়োজন৷

আমরা কোথায় যাচাইকারী এবং টাইপ অনুমানের জন্য পরীক্ষা রাখি?

ops_stablehlo.mlir-এ প্রতিটি যাচাইকরণ ত্রুটির জন্য ops-এর ইতিবাচক ঘটনা এবং (অন্তত) 1টি নেতিবাচক পরীক্ষা রয়েছে। এটি অনুমানকৃত রিটার্ন টাইপটি আসল ফলাফলের প্রকারের সাথে সামঞ্জস্যপূর্ণ (এর মতো নয়!) তা পরীক্ষা করতে সক্ষম।

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 নামে একটি পৃথক পরীক্ষার ফাইল যোগ করার কথা বিবেচনা করুন।