Die erforderlichen Schritte finden Sie unter vhlo_checklist.md.
Änderungen an VHLO.
Was ist der VHLO-Dialekt?
Der VHLO-Dialekt (versioned StableHLO) wird für Serialisierung und Stabilität verwendet. Sie liefert einen Snapshot des StableHLO-Dialekts zu einem bestimmten Zeitpunkt, Versionsverwaltung einzelner Programmelemente.
VHLO ist ein Dialekt, für den nur Add-ons möglich sind, mit versionierten Vorgängen, Typen und Attributen. Das bedeutet, dass ein Element, das dem Dialekt hinzugefügt wurde, nicht mehr geändert werden kann. die sich auf die Semantik auswirken.
Alle Änderungen an Vorgang, Typ oder Attribut erfordern das Hinzufügen einer neuen Version zum
den Dialekt. Wurde beispielsweise in einer Tabelle ein hypothetisches my_op-Objekt zu StableHLO hinzugefügt,
0.9.0, aber in 0.11.0 geändert wurde, sehen wir in VHLO Folgendes:
// This represents the StableHLO version of the op from 0.9.0 -> 0.10.0
// Both the lower and the upper bound of versions are inclusive
def VHLO_MyOpV1 : VHLO_Op<"my_op_v1", "0.9.0", "0.10.0"> {
let arguments = (ins
VHLO_AnyType:$operand
);
let results = (outs VHLO_AnyType:$result);
}
// This represents the StableHLO version of the op from 0.11.0 -> current
def VHLO_MyOpV2 : VHLO_Op<"my_op_v2", "0.11.0", "current"> {
let arguments = (ins
VHLO_AnyType:$operand,
VHLO_AnyAttr:$attr // New attribute added to StableHLO in 0.11.0
);
let results = (outs VHLO_AnyType:$result);
}
Der StableHLO-Dialekt hat nur die neueste Version der Vorgänge. Im Rennen
Beispiel: Der StableHLO-Dialekt bei v0.11.0 hätte nur StableHLO_MyOp
mit operand und attr, während VHLO jede Phase der Operationen
Entwicklung.
Warum ist VHLO nützlich?
Mit einem versionierten Dialekt können wir uns auf frühere Versionen des StableHLO-Opset. So wird die Vorwärts- und Abwärtskompatibilität in Conversions zwischen Operationen im VHLO-Dialekt.
Aufwärtskompatibilität:Die Aufwärtskompatibilität wird durch die Konvertierung erzielt. auf VHLO und das Downgrade auf eine Zielversion. Wenn jede Operation/Typ/Attraktion ein Downgrade des VHLO-Programms auf die Zielversion durchgeführt werden, auf einem Nutzer, der eine Version ausführt, deserialisierbar und in StableHLO konvertiert werden kann größer oder gleich der Zielversion ist, da VHLO über einen Snapshot der Opset zu diesem Zeitpunkt.
Diese Downgrade-Conversion schlägt fehl, wenn Vorgänge oder Funktionen, die in der Vorgängerversion verwendet. Das bedeutet, dass die Aufwärtskompatibilität auf dem Ersteller und nicht während der Laufzeit entdeckt werden.
Abwärtskompatibilität:Die Abwärtskompatibilität wird durch ein Upgrade VHLO-Vorgänge auf ihre neueste Version (falls erforderlich) und wandeln diese dann wieder in StableHLO fest. Für alle VHLO-Programme innerhalb des Kompatibilitätsfensters kann ein Upgrade durchgeführt werden StableHLO, d. h., verschiedene Versionen von Nutzern können dasselbe VHLO-Nutzlast aus einer früheren Version.
Noch wichtiger ist, dass VHLO hinter der Serialisierung abstrahiert ist. Das bedeutet, dass ML Frameworks (Ersteller) müssen nur auf StableHLO-Operations und Compiler abzielen. Backends (Nutzer) müssen nur die neueste Version unterstützen. Dies ist die StableHLO-Vorgang festgelegt. Die Umrechnung in und aus VHLO wird mithilfe von Maschinen abgewickelt. im StableHLO-Repository verwaltet.
MLIR-Bytecode-Formatversionen
Um die Aufwärtskompatibilität zu gewährleisten, haben StableHLO-Versionen eine zugehörige Version des MLIR-Bytecode-Formats. Außerdem wird die neueste Version der StableHLO verwendet die neueste Version des MLIR-Bytecode-Formats. Wenn der Parameter MLIR Bytecode Format-Version erhöht, die nächste Version von StableHLO Erhöhen Sie die Nebenversion und aktualisieren Sie Version.cpp. um die neueste Version des MLIR-Bytecode-Formats zu verwenden.
Details zum MLIR-Bytecode-Format und zu den Gründen für dessen Verwendung in StableHLO Siehe bytecode.md.