Контрольный список переводчика StableHLO

В этом документе мы суммируем рекомендации по реализации и проверке функций переводчика. Мы намеренно включили несколько вспомогательных действий, связанных с верификатором и выводом типа, с целью добиться прогресса на этих фронтах параллельно с реализацией интерпретатора.

При реализации оп.

  1. Предоставьте явно написанную стратегию тестирования (в описании PR), подобную этой , чтобы использовать ее в качестве справочного материала при рассмотрении методов проверки и вывода типа, а также соответствующих тестов. Рецензент дважды проверит полноту описания.
  2. Обратитесь к hlo_evaluator , чтобы выявить сложные детали реализации и потенциальные пробелы в функциональности.
  3. Сохраняйте билеты для соответствующих компонентов программного обеспечения, если вы обнаружите какие-либо ошибки или недостающую функциональность.

После реализации оп.

  1. В StablehloOps.td :

    1. Убедитесь, что summary в ODS операции соответствует стандартному формату. (сопутствующий билет )

    2. Добавьте комментарии, ссылающиеся на метки ограничений (например, Cn или In ) из спецификации в формате xyz_cn или xyz_in для op XyzOp , чтобы определить соответствие между ограничениями в ODS и спецификацией. В следующем примере показано, как добавить метки ограничений в качестве комментариев рядом с mlir Traits и TypeConstraints . Примечание xyz_c4 относится к ограничениям, определенным в классе StableHLO_FooOp (например, StableHLO_ShapedInterfaceOp , StableHLO_UnaryElementwiseOp , StableHLO_Op и т. д.).

       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. В TypeInference.cpp и StablehloOps.cpp :

    1. Удалите комментарии, в которых говорится что-то вроде «Проверьте следующие свойства: ...».
    2. Добавьте комментарии, ссылающиеся на метки ограничений (например, Cn или In ) из спецификации в формате xyz_cn или xyz_in для op XyzOp , чтобы определить, какие части верификаторов и функций формы соответствуют каким ограничениям в спецификации.
      1. Вполне нормально иметь комментарий с несколькими метками ограничений или иметь несколько комментариев с одной и той же меткой ограничения. Все зависит от того, как будут реализованы ограничения. Если существуют последовательные ограничения, сократите их как xyz_cn...xyz_cm, xyz_in...xyz_jn .
      2. В случае несоответствия ограничений в реализации VS и ограничениях в спецификации убедитесь, что существует открытая проблема, отражающая это несоответствие.

  3. В тестах переводчика :

    1. Добавьте файл с именем <op_mnemonic>.mlir .
    2. Пишите тесты, следуя рекомендациям по тестированию .

  4. В каталоге тестовых данных :

    1. Запустите все отключенные тесты, на которые распространяется новая добавленная операция.
    2. Если тесты пройдены, включите их, преобразовав RUN-DISABLED в RUN .
    3. Если тест не пройден по какой-либо причине, кроме несоответствия точности, исправьте реализацию/тест.
    4. В случае несоответствия точности пометьте тест меткой RUN-DISABLED(#1278) (если это еще не сделано).

  5. В ops_stablehlo.mlir :

    1. Убедитесь, что существует хотя бы один тест (положительный или отрицательный) для каждого ограничения в методах проверки и вывода типа; ограничения, охватываемые ODS, не будут проверяться. Эти тесты в основном будут отрицательными, проверяющими несоблюдение ограничений, или положительными, проверяющими правильность предполагаемой формы.
    2. Убедитесь, что все тесты, относящиеся к тестируемой операции, собраны вместе.
    3. Убедитесь, что все тесты, относящиеся к тестируемой операции, предваряются горящим макросом CHECK-LABEL .
    4. Выберите имя функции тестов, используя формат xyz_cn_im_... для ограничений функции тестирования Cn , Im и т. д. для операции XyzOp . В случаях, когда предложенный формат неприменим, сохраните существующее название.
    5. После завершения вышеуказанного шага отсортируйте все тесты, относящиеся к тестируемой операции, в алфавитном порядке по имени функции.
    6. Продолжайте добавлять тесты до тех пор, пока CCOV не покажет >= 90% покрытия операции.

  6. В infer_stablehlo.mlir :

    1. Убедитесь, что в этом файле присутствуют все ограничения, связанные с тестами вывода формы, в соответствии с теми же рекомендациями по присвоению имен, указанными выше.
    2. Переместите все тесты вывода формы из файла ops_stablehlo.mlir в этот файл.

  7. В спец.md :

    1. Добавьте ссылку на stablehlo/tests/interpret/<op_mnemonic>.mlir в раздел «Примеры» (например, «Дополнительные примеры» ).
    2. Убедитесь, что в спецификации есть только 1 пример.
    3. Убедитесь, что пример спецификации соответствует рекомендациям по тестированию .
    4. Убедитесь, что пример теста спецификации интерпретируем.
    5. Убедитесь, что пример спецификации такой же, как и в ODS.

  8. В status.md :

    1. Обновите столбец «Интерпретатор» до значения « yes .