Tłumacz języka StableHLO – lista kontrolna

W tym dokumencie podsumowujemy wytyczne wdrażania i sprawdzania propozycji dla tłumacza. Celowo dodaliśmy kilka działań pomocniczych związanych z weryfikatorem i wnioskowaniem o typach, z pomysłem na dokonanie postępów w tych obszarach wraz z implementacją tłumaczenia przez tłumacza.

Podczas wdrażania op

1. Podaj jasno określoną strategię testowania (w opisie PR) podobną do tej, aby móc ją wykorzystać jako punkt odniesienia podczas sprawdzania metod weryfikacji i typowania oraz odpowiednich testów. Weryfikator dokładnie sprawdzi, czy opis jest pełny.
2. Skonsultuj się z firmą hlo_evaluator, aby wykryć szczegóły dotyczące implementacji i potencjalne luki w funkcjonalności.
3. Jeśli znajdziesz błędy lub brakujące funkcje, prześlij zgłoszenia dotyczące odpowiednich komponentów oprogramowania.

Po wdrożeniu opcji

1. W pliku StablehloOps.td:

   1. Upewnij się, że summary w pliku ODS op jest zgodny ze standardowym formatem. (powiązane zgłoszenie)

   2. Dodaj komentarze odwołujące się do etykiet ograniczeń (np. Cn lub In) ze specyfikacji w formacie xyz_cn lub xyz_in, dla op XyzOp, aby wskazać zgodność ograniczeń w pliku ODS ze specyfikacją. Poniższy przykład pokazuje, jak dodać etykiety ograniczeń jako komentarze obok 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, które zawierają takie informacje jak „Zweryfikuj te właściwości: ...”.
   2. Dodaj komentarze odwołujące się do etykiet ograniczeń (np. Cn lub In) z specyfikacji w formacie xyz_cn lub xyz_in, dla opcji XyzOp, aby wskazać, które części weryfikatorów i funkcji kształtowania odpowiadają któremu ograniczeniu w specyfikacji.
      1. Możesz mieć komentarz z wieloma etykietami ograniczeń lub wiele komentarzy z tą samą etykietą ograniczenia. Wszystko zależy od tego, jak są one implementowane. Jeśli występują kolejne ograniczenia, skróć je do xyz_cn...xyz_cm, xyz_in...xyz_jn.
      2. Jeśli występują rozbieżności między ograniczeniami w implementacji a ograniczeniami w specyfikacji, otwórz zgłoszenie problemu, aby odzwierciedlić tę rozbieżność.

3. W testach tłumaczacza:

   1. Dodaj plik o nazwie <op_mnemonic>.mlir.
   2. Pisz testy zgodnie z wytycznymi dotyczącymi testowania.

4. W katalogu testdata:

   1. Uruchom wszystkie wyłączone testy uwzględnione w nowo dodanej operacji.
   2. Jeśli testy się powiodą, włącz je, zmieniając wartość RUN-DISABLED na RUN.
   3. Jeśli test się nie powiedzie z jakiegoś powodu innego niż niedopasowanie dokładności, napraw implementację lub test.
   4. W przypadku niezgodności precyzji otaguj test tagiem RUN-DISABLED(#1278) (jeśli nie został już oznaczony).

5. W pliku ops_stablehlo.mlir:

   1. Upewnij się, że w metodach weryfikatora i typu wnioskowania jest co najmniej jeden test (pozytywny lub negatywny) dla każdej reguły w weryfikatorze; reguły objęte w ODS nie będą testowane. Te testy będą w większości negatywne, ponieważ sprawdzają, czy ograniczenia nie są spełnione, lub pozytywne, ponieważ sprawdzają, czy kształt jest prawidłowy.
   2. Upewnij się, że wszystkie testy związane z testowanym elementem zostały przeprowadzone razem.
   3. Upewnij się, że wszystkie testy związane z testowanym działaniem mają makro CHECK-LABEL na początku.
   4. Wybierz nazwę funkcji testów, używając formatu xyz_cn_im_... dla ograniczeń testowania funkcji Cn, Im itd. dla opcji XyzOp. Jeśli proponowany format nie jest odpowiedni, zachowaj obecną nazwę.
   5. Po wykonaniu powyższego kroku posortuj alfabetycznie wszystkie testy związane z testem operacji według nazwy funkcji.
   6. Dodawaj testy, aż ccov wykaże zasięg przekraczający 90% dla op.

6. W pliku infer_stablehlo.mlir:

   1. Upewnij się, że w tym pliku znajdują się wszystkie ograniczenia związane z testami wnioskowania o kształcie, zgodnie z wytycznymi dotyczącymi nazewnictwa podanymi powyżej.
   2. Przesuń wszystkie testy wnioskowania o kształcie z pliku ops_stablehlo.mlir do tego pliku.

7. W pliku spec.md:

   1. Dodaj link do stablehlo/tests/interpret/<op_mnemonic>.mlir w sekcji „Przykłady” (np. Więcej przykładów).
   2. Upewnij się, że specyfikacja zawiera tylko 1 przykład.
   3. Upewnij się, że przykład specyfikacji jest zgodny z wytycznymi dotyczącymi testowania.
   4. Upewnij się, że test przykładu specyfikacji jest zrozumiały.
   5. Upewnij się, że przykładowa specyfikacja jest taka sama jak w atrybucie pozasądowego rozstrzygania sporów.

8. W pliku status.md:

   1. Zaktualizuj kolumnę „Interpreter” na yes.