Consultez vhlo_checklist.md pour connaître la procédure à suivre pour créer
les modifications apportées au VHLO.
Qu'est-ce que le dialecte VHLO ?
Le dialecte VHLO (Versioned StableHLO) est utilisé pour la sérialisation et la stabilité. Il fournit un instantané du dialecte StableHLO à un moment donné en la gestion des versions des éléments individuels du programme.
VHLO est un dialecte d'ajout uniquement avec des opérations, des types et des attributs avec gestion des versions, ce qui signifie qu'une fois qu'un élément géographique est ajouté au dialecte, il ne peut plus être modifié. ayant un impact sur la sémantique.
Toute modification d'une opération, d'un type ou d'un attribut nécessite l'ajout d'une nouvelle version à
le dialecte. Par exemple, si un my_op fictif a été ajouté à StableHLO dans
0.9.0, mais qui a été modifiée en 0.11.0, nous aurions ceci dans VHLO:
// 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);
}
Le dialecte StableHLO ne contient que la dernière version des opérations. Dans la course
Par exemple, le dialecte StableHLO de la version 0.11.0 n'aurait que le StableHLO_MyOp
contenant operand et attr, tandis que le VHLO capture chaque phase de l'opération
l'évolution de la situation.
En quoi le VHLO est-il utile ?
Le fait d'avoir un dialecte versionné nous permet de cibler les versions précédentes du opset StableHLO. Cela encapsule la rétrocompatibilité les conversions entre les opérations dans le dialecte VHLO.
Compatibilité ascendante:la rétrocompatibilité est fournie en convertissant passer au VHLO et revenir à une version cible. Si chaque opération/type/attr d'une Le programme VHLO peut être rétrogradé vers la version cible, il sera garanti désérialisable et convertible en StableHLO sur un client exécutant une version supérieure ou égale à la version cible, car le VHLO dispose d'un instantané opset à ce moment-là.
La conversion à la version antérieure échouera si les opérations ou les fonctionnalités qui n'existent pas dans le la version précédente de l'opset sont utilisées. Cela signifie que la rétrocompatibilité est découvert sur le producteur, plutôt qu'au moment de l'exécution.
Rétrocompatibilité:la rétrocompatibilité est assurée en mettant à niveau les opérations VHLO vers leur dernière version (si nécessaire), puis reconvertir l’opération en StableHLO. Tous les programmes VHLO de la fenêtre de compatibilité peuvent être mis à niveau vers StableHLO, ce qui signifie que différentes versions des consommateurs peuvent désérialiser la même charge utile VHLO d'une version précédente.
Plus important encore, le VHLO est extrait derrière la sérialisation. Ainsi, le ML les frameworks (producteurs) ne doivent cibler que les opérations StableHLO, et le compilateur les backends (consommateurs) n'ont besoin que de la dernière version, à savoir Ensemble d'opérations StableHLO. Les conversions vers et depuis les vHLO sont gérées à l'aide de machines gérées dans le dépôt StableHLO.
Versions du format d'octet MLIR
Afin de maintenir la rétrocompatibilité, les versions StableHLO disposent d'une version du format d'octet MLIR associée. De plus, la dernière version de StableHLO utilise la dernière version du format d'octet MLIR. Lorsque la version MLIR Bytecode Format est incrémentée, la prochaine version de StableHLO incrémentez la version mineure et mettez à jour le fichier Version.cpp. d'utiliser la dernière version du format MLIR Bytecode.
Pour en savoir plus sur le format d'octet MLIR et sur sa raison d'être dans StableHLO, voir bytecode.md.