Lista kontrolna interpretowania języka StableHLO

W tym dokumencie podsumowujemy wytyczne dotyczące wdrażania i sprawdzania operacji dla tłumacza. Celowo uwzględniliśmy kilka działań pomocniczych związanych z weryfikacją i wnioskowaniem typu, mając na uwadze pomysł na postępy w tych obszarach, oprócz wdrożenia tłumacza.

Podczas wdrażania operacji

1. Udostępnij wyraźnie pisemną strategię testowania (w opisie PR), która jest podobna do tej, i wykorzystaj ją jako punkt odniesienia przy sprawdzaniu metod weryfikacji i wnioskowania typu oraz odpowiednich testów. Weryfikator dokładnie sprawdzi, czy opis jest wyczerpujący.
2. Zajrzyj na stronę hlo_evaluator, aby poznać trudne szczegóły implementacji i potencjalne luki w funkcjach.
3. Jeśli znajdziesz błędy lub brakujące funkcje, możesz przesyłać zgłoszenia dotyczące odpowiednich komponentów oprogramowania.

Po wdrożeniu operacji

1. W StablehloOps.td:

   1. Upewnij się, że element summary w ODS operacji jest zgodny ze standardowym formatem. (powiązany bilet)

   2. Dodaj komentarze odwołujące się do etykiet ograniczeń (np. Cn lub In) ze specyfikacji w formacie xyz_cn lub xyz_in dla operacji XyzOp, aby określić zależności między ograniczeniami w ODS a specyfikacją. Poniższy przykład pokazuje, jak dodać etykiety ograniczeń jako komentarze obok systemów mlir Traits i TypeConstraints. Uwaga xyz_c4 odnosi się do ograniczeń zdefiniowanych w klasie StableHLO_FooOp (np. StableHLO_ShapedInterfaceOp, StableHLO_UnaryElementwiseOp, StableHLO_Op itp.).

       def StableHLO_XyzOp: StableHLO_FooOp<"xyz", [Trait1,
           Trait2 /*xyz_c1, xyz_c2*/, InferTensorType /*xyz_c3*/]> { /*xyz_c4*/
            ...
         let summary = "Xyz operation";
         let arguments = (ins
            1DTensorOf<[HLO_Float]>:$a, /*xyz_c5, xyz_i1*/
            HLO_Tensor:$b, /*xyz_i2*/
            ....
         );
      );
      

2. W plikach TypeInference.cpp i StablehloOps.cpp:

   1. Usuń komentarze typu „Zweryfikuj te usługi: ...”.
   2. Dodaj komentarze odwołujące się do etykiet ograniczeń (np. Cn lub In) ze specyfikacji w formacie xyz_cn lub xyz_in dla operacji XyzOp, aby określić, które części weryfikatorów i funkcji kształtu odpowiadają określonym ograniczeniom w specyfikacji.
      1. Można mieć komentarz z wieloma etykietami ograniczenia lub wiele komentarzy z tą samą etykietą ograniczenia. Wszystko zależy od sposobu stosowania ograniczeń. Jeśli występują następujące po sobie ograniczenia, skróć je jako xyz_cn...xyz_cm, xyz_in...xyz_jn.
      2. W razie rozbieżności między ograniczeniami w implementacji a tymi w specyfikacji upewnij się, że występuje otwarty problem odzwierciedlający tę rozbieżność.

3. W przypadku testów tłumaczeniowych:

   1. Dodaj plik o nazwie interpret_<op_mnemonic>.mlir.
   2. Napisz testy zgodnie ze wskazówkami dotyczącymi testowania.

4. W katalogu danychtestowych:

   1. Uruchom wszystkie wyłączone testy, które są objęte nowo dodaną operacją.
   2. Jeśli testy zakończą się powodzeniem, włącz je, konwertując RUN-DISABLED na RUN.
   3. Jeśli test zakończy się z innego powodu niż niezgodności w dokładności, napraw implementację/test.
   4. W przypadku niezgodności precyzji oznacz test tagiem RUN-DISABLED(#1278) (jeśli nie jest jeszcze zakończony).

5. W pliku ops_stablehlo.mlir:

   1. Upewnij się, że dla każdego ograniczenia w narzędziu do weryfikacji i metod wnioskowania typu występuje co najmniej jeden test (pozytywny lub ujemny). Ograniczenia uwzględnione w ODS nie będą testowane. Będą one w większości ujemne oraz że ograniczenia nie będą spełnione lub będą dodatnie, a także sprawdź, czy wywnioskowany kształt jest prawidłowy.
   2. Upewnij się, że wszystkie testy związane z testowaną operacjami są uwzględnione w jednym miejscu.
   3. Sprawdź, czy wszystkie testy związane z testowaną operacjami są poprzedzone makrem CHECK-LABEL.
   4. Wybierz nazwę funkcji testów w formacie xyz_cn_im_... na potrzeby ograniczeń testowania funkcji Cn, Im itp. dla operacji XyzOp. Jeśli proponowany format nie ma zastosowania, zachowaj istniejącą nazwę.
   5. Po wykonaniu powyższego kroku posortuj alfabetycznie wszystkie testy związane z operacją w ramach testu, według nazwy funkcji.
   6. Dodawaj testy tak długo, aż ccov pokaże >= 90% pokrycia dla operacji.

6. W pliku infer_stablehlo.mlir:

   1. Sprawdź, czy w tym pliku znajdują się wszystkie ograniczenia związane z testami wnioskowania kształtów zgodnie z podanymi wyżej wytycznymi dotyczącymi nazewnictwa.
   2. Przenieś do tego pliku wszystkie testy wnioskowania na podstawie kształtów z pliku ops_stablehlo.mlir.

7. W pliku spec.md:

   1. W sekcji „Przykłady” dodaj link do tabeli interpret_<op_mnemonic>.mlir (np. Więcej przykładów).
   2. Upewnij się, że specyfikacja zawiera tylko 1 przykład.
   3. Upewnij się, że przykładowa specyfikacja jest zgodna z wytycznymi dotyczącymi testowania.
   4. Dopilnuj, aby przykładowy test specyfikacji był zrozumiały.
   5. Upewnij się, że przykład specyfikacji jest taki sam jak w ODS.

8. W pliku status.md:

   1. Zmień ustawienie kolumny „Tłumacz” na yes.