Checkliste für StableHLO-Spezifikationen

In diesem Dokument sind die Richtlinien zum Prüfen von Änderungen an der Spezifikation zusammengefasst. Im Moment geht es bei diesen Änderungen in der Regel darum, mehrere Dinge in mehreren Quellen zu prüfen. Daher fasst dieses Dokument sie alle zusammen, um die Überprüfung zu vereinfachen:

  1. Prüfen Sie, ob in der Spalte „Specification“ in status.md „yes“ steht. Fügen Sie eine Zeile hinzu, wenn Sie eine neue Operation hinzufügen.
  2. Prüfen Sie, ob der Abschnittstitel mit der Mnemonie des Vorgangs in der ODS übereinstimmt.
  3. Prüfen Sie, ob der Abschnitt „Semantics“ mit Operation Semantics von XLA übereinstimmt.
  4. Prüfen Sie, ob die Abschnitte „Inputs“ und „Outputs“ Folgendes prüfen:
    1. Listen Sie die gleichen Elemente wie die ODS auf.
    2. Geben Sie dieselben Elemente an wie in HloInstruction::CreateFromProto.
    3. Sie werden genau wie bei ODS angeordnet.
    4. Prüfen Sie bei Abweichungen, ob entsprechende Tickets vorhanden sind.
  5. Prüfen Sie, ob im Bereich „Einschränkungen“
    1. Entspricht shape_inference.cc von XLA.
    2. Übereinstimmung mit hlo_verifier.cc von XLA
    3. Stimmt mit der ODS überein.
    4. Stimmt mit StablehloOps.cpp überein.
    5. Prüfen Sie bei Abweichungen, ob entsprechende Tickets vorhanden sind. Verknüpfen Sie alle diese Tickets in der Spezifikation an möglichst konkreten Orten. Wenn ein Ticket beispielsweise eine nicht implementierte Einschränkung betrifft, verknüpfen Sie das Ticket direkt in dieser Einschränkung.
    6. Wenn die entsprechenden Teile von ODS und StablehloOps.cpp der Spezifikation entsprechen, prüfen Sie, ob in den Spalten „Verification“ und „Type Inference“ in status.md „yes“ angegeben ist.
  6. Prüfen Sie, ob im Abschnitt „Beispiele“
    1. Es gibt nur ein Beispiel. (Zukünftig verlinken wir auf weitere Beispiele aus der StableHLO-Interpreter-Testsuite.)
    2. Verwendet gültige MLIR-Syntax durch Ausführen von stablehlo-opt für Codebeispiele.
    3. Verwendet eine generische MLIR-Syntax, die durch Ausführen von stablehlo-opt -mlir-print-op-generic abgerufen werden kann. Wir halten uns an die allgemeine Syntax in der Spezifikation, um zu vermeiden, dass die Spezifikation bei Pretprinter-Änderungen geändert werden muss.
  7. Prüfen Sie, ob description in der ODS des Vorgangs:
    1. Enthält den ersten Satz der Spezifikation
    2. Danach gelangen Sie zum entsprechenden Abschnitt der Spezifikation.
    3. Dann wird das gleiche Beispiel wie für die Spezifikation verwendet, allerdings mit ziemlich Syntax, die durch Ausführen von stablehlo-opt abgerufen werden kann.
  8. Prüfen Sie, ob die Dateien für die Implementierung von Überprüfungs- und Typinferenzeinschränkungen den folgenden Richtlinien entsprechen:
    1. Folgen Sie der Richtlinie Nr. 1 für StablehloOps.td.
    2. Folgen Sie der Richtlinie #2 für TypeInference.cpp und StablehloOps.cpp.
    3. Folgen Sie der Richtlinie #5 für ops_stablehlo.mlir.
    4. Folgen Sie der Richtlinie #6 für infer_stablehlo.mlir.
  9. Bewerten Sie die Möglichkeiten auf Nebenwirkungen und Spekulationsfähigkeit.
    1. Wenn der Vorgang keine Nebenwirkungen hat und immer spekulativ ist, weisen Sie ihm das Merkmal Pure zu. Dies ist selten, da die meisten Vorgänge dynamische Formen zulassen. Dies kann zu Formabweichungen während der Laufzeit führen. Dies ist ein undefiniertes Verhalten. Einige Vorgänge können auch in anderen Situationen ein undefiniertes Verhalten haben. Die überwiegende Mehrheit der Operationen hat keine Nebeneffekte (sie sollten die Eigenschaft NoMemoryEffect haben).
    2. Die meisten Operationen fallen in eine der HLO_SpeculatableIf*-Traits. Wenn der Vorgang in keine dieser Kategorien passt, weisen Sie ihm das Trait ConditionallySpeculatable zu und implementieren Sie die Schnittstellenmethoden. Fügen Sie stablehlo/tests/ops_speculatability.mlir Tests hinzu, um die Spekulationslogik abzudecken.