Eine Anleitung zum Ändern von VHLO findest du unter vhlo_checklist.md.
Was ist der VHLO-Dialekt?
Der VHLO-Dialekt (Versioned StableHLO) wird für die Serialisierung und Stabilität verwendet. Sie bietet einen Snapshot des StableHLO-Dialekts zu einem bestimmten Zeitpunkt durch Versionsverwaltung für einzelne Programmelemente.
VHLO ist ein nur zum Hinzufügen vorgesehener Dialekt mit versionierten Vorgängen, Typen und Attributen. Das bedeutet, dass eine Funktion, die dem Dialekt hinzugefügt wurde, nicht mehr so geändert werden kann, dass sich das auf die Semantik auswirkt.
Bei Änderungen an einer Operation, einem Typ oder einem Attribut muss dem Dialekt eine neue Version hinzugefügt werden. Wenn beispielsweise eine hypothetische my_op in StableHLO in 0.9.0 hinzugefügt, aber in 0.11.0 geändert wurde, würde in VHLO Folgendes angezeigt:
// 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 Beispiel würde der StableHLO-Dialekt in v0.11.0 nur den StableHLO_MyOp mit operand und attr enthalten, während VHLO jede Phase der Entwicklung des Vorgangs erfasst.
Warum ist VHLO nützlich?
Durch einen versionierten Dialekt können wir auf vorherige Versionen des StableHLO-Opsets abzielen. Dadurch wird die Vorwärts- und Abwärtskompatibilität bei der Umwandlung zwischen Operatoren im VHLO-Dialekt berücksichtigt.
Vorwärtskompatibilität: Die Vorwärtskompatibilität wird durch die Umwandlung in VHLO und das Downgrade von Vorgängen auf eine Zielversion erreicht. Wenn jedes Op/Typ/Attribut in einem VHLO-Programm auf die Zielversion herabgestuft werden kann, kann es garantiert auf einem Verbraucher, der eine Version ausführt, die der Zielversion entspricht oder höher ist, deserialisiert und in StableHLO umgewandelt werden, da VHLO zu diesem Zeitpunkt einen Snapshot des OpSets hat.
Diese Downgrade-Konvertierung schlägt fehl, wenn Vorgänge oder Funktionen verwendet werden, die in der vorherigen Version des Operationsets nicht vorhanden sind. Das bedeutet, dass die zukünftige Kompatibilität beim Erzeuger und nicht bei der Laufzeit erkannt wird.
Abwärtskompatibilität: Die Abwärtskompatibilität wird durch ein Upgrade der VHLO-Vorgänge auf die neueste Version (falls erforderlich) und die anschließende Umwandlung eines Vorgangs in StableHLO sichergestellt. Alle VHLO-Programme innerhalb des Kompatibilitätszeitraums können auf StableHLO umgestellt werden. Das bedeutet, dass verschiedene Versionen von Verbrauchern dieselbe VHLO-Nutzlast aus einer früheren Version deserialisieren können.
Noch wichtiger ist, dass VHLO hinter der Serialisierung abstrahiert ist. Das bedeutet, dass ML-Frameworks (Produzenten) nur auf StableHLO-Vorgänge ausgerichtet sein müssen und Compiler-Backends (Nutzer) nur die neueste Version unterstützen müssen, also den StableHLO-Vorgabensatz. Die Umwandlungen von und zu VHLO werden mithilfe von Maschinen durchgeführt, die im StableHLO-Repository verwaltet werden.
MLIR-Bytecode-Formatversionen
Zur Aufrechterhaltung der Vorwärtskompatibilität haben StableHLO-Versionen eine zugehörige MLIR-Bytecode-Formatversion. Außerdem verwendet die neueste Version von StableHLO die neueste Version des MLIR-Bytecode-Formats. Wenn die Version des MLIR-Bytecode-Formats erhöht wird, wird im nächsten Release von StableHLO die Minor-Version erhöht und Version.cpp wird so aktualisiert, dass die neueste Version des MLIR-Bytecode-Formats verwendet wird.
Weitere Informationen zum MLIR-Bytecode-Format und zu den Gründen für seine Verwendung in StableHLO finden Sie unter bytecode.md.