Le workflow de développement XLA est généralement centré sur
HLO IR, qui représente les fonctions isolées
le calcul fourni au compilateur. XLA intègre plusieurs outils de ligne de commande
(décrit ci-dessous) qui utilisent un HLO et l'exécutent, ou fournissent un
est une étape de compilation intermédiaire. L'utilisation de ces outils est inestimable
le cycle d'itération de compile->modify->run, l'objectif HLO étant à la fois lisible et
hackable, et le modifier et l'exécuter de
manière itérative est souvent le moyen le plus rapide
et corriger les performances
ou le comportement d'un XLA.
Le moyen le plus simple d'obtenir le HLO d'un programme en cours de compilation avec XLA est
utilisez généralement la variable d'environnement XLA_FLAGS:
$ XLA_FLAGS=--xla_dump_to=/tmp/myfolder ./myprogram-entry-point
qui stocke tous les fichiers HLO avant optimisation dans le dossier spécifié, ainsi que avec de nombreux autres artefacts utiles.
Extraits HLO en cours d'exécution: run_hlo_module
L'outil run_hlo_module fonctionne sur les HLO de pré-optimisation et, par défaut,
regroupe la compilation, l'exécution et la comparaison avec l'interpréteur de référence
la mise en œuvre. Par exemple, l'appel habituel pour exécuter un fichier d'entrée
Pour vérifier qu'il est correct, computation.hlo sur un GPU NVIDIA:
$ run_hlo_module --platform=CUDA --reference_platform=Interpreter computation.hlo
Comme avec tous les outils, vous pouvez utiliser --help pour obtenir la liste complète des options.
Exécution d'extraits HLO compatibles avec SPMD: multihost_hlo_runner
L'exécuteur HLO multi-hôte est un outil très similaire, mais il prend en charge SPMD, y compris la communication entre hôtes. Voir Exécuteur HLO multi-hôtes pour en savoir plus.
Rediffusion multi-HLO
L'appel avec plusieurs modules est compatible avec run_hlo_module et
hlo_runner_main, qui est souvent pratique pour relire tous les modules d'un vidage
répertoire:
$ hlo_runner_main /dump/*before_optimizations*
Passes/étapes en cours d'exécution de la compilation HLO: hlo-opt
Lors du débogage ou de la compréhension du fonctionnement du compilateur, il est souvent utile pour obtenir l'expansion d'un matériel particulier à un moment donné (HLO, HLO optimisé, TritonIR ou LLVM) pour un HLO donné (stable) saisie.
hlo-opt accepte plusieurs étapes de sortie: PTX, HLO après optimisation,
LLVM IR avant optimisations, ou TritonIR. L'ensemble exact des étapes acceptées
dépend de la plate-forme (le PTX est spécifique à NVIDIA, par exemple). Vous pouvez le voir en utilisant
la commande --list-stages:
$ hlo-opt --platform=CUDA --list-stages
hlo
llvm
ptx
Après avoir sélectionné une étape, l'utilisateur peut écrire le résultat de la conversion pour un une plate-forme donnée à un flux donné:
$ hlo-opt myinput.hlo --platform=CUDA --stage=llvm
qui imprimerait le vidage sur stdout (ou dans un fichier donné si -o était spécifié).
Utilisation sans appareil
L'accès à un GPU n'est pas nécessaire pour la majeure partie de la compilation. En spécifiant un la spécification GPU sur la ligne de commande. Par exemple, Sortie PTX sans accès accélérateur:
$ hlo-opt --platform=CUDA --stage=llvm --xla_gpu_target_config_filename=(pwd)/tools/data/gpu_specs/a100_pcie_80.txtpb input.hlo
Les spécifications des GPU courants sont fournies avec le compilateur, et le fichier fourni est
sérialisation de chaînes de device_description.proto:
gpu_device_info {
cuda_compute_capability {
major: 8
minor: 0
}
threads_per_block_limit: 1024
threads_per_warp: 32
shared_memory_per_block: 127152
shared_memory_per_core: 65536
threads_per_core_limit: 2048
core_count: 6192
fpus_per_core: 64
block_dim_limit_x: 2147483647
block_dim_limit_y: 65535
block_dim_limit_z: 65535
memory_bandwidth: 2039000000000
l2_cache_size: 4194304
clock_rate_ghz: 1.1105
device_memory_size: 79050250240
}
platform_name: "CUDA"
La compilation sans appareil peut rencontrer des problèmes si un réglage automatique est requis. Heureusement, nous pouvons également les fournir via la ligne de commande:
$ hlo-opt --platform=CUDA --stage=llvm --xla_gpu_target_config_filename=gpu_specs/a100_pcie_80.txtpb --xla_gpu_load_autotune_results_from=results.textpb input.hlo
Le fichier d'autoréglage est une sérialisation de texte de autotune_results.proto, avec
exemple:
version: 3
results {
device: "CUDA: 8.0, Cores: 108, GPU clock: 1.41 GHz, Memory bandwidth: 1555 GB/s, L2 cache: 40 MB"
hlo: "{\n tmp_0 = f16[1,16,17,3]{3,2,1,0} parameter(0)\n tmp_1 = f16[16,51]{1,0} bitcast(f16[1,16,17,3]{3,2,1,0} tmp_0)\n tmp_2 = s8[16,17,3]{2,1,0} parameter(1)\n tmp_3 = s8[51,16]{0,1} bitcast(s8[16,17,3]{2,1,0} tmp_2)\n tmp_4 = f16[51,16]{0,1} convert(s8[51,16]{0,1} tmp_3)\n tmp_5 = f16[16,16]{1,0} dot(f16[16,51]{1,0} tmp_1, f16[51,16]{0,1} tmp_4), lhs_contracting_dims={1}, rhs_contracting_dims={0}\n ROOT tmp_6 = f16[1,16,16]{2,1,0} bitcast(f16[16,16]{1,0} tmp_5)\n}"
result {
run_time {
nanos: 31744
}
triton {
block_m: 32
block_n: 32
block_k: 32
split_k: 1
num_stages: 1
num_warps: 4
}
}
}
La base de données de réglage automatique peut être sérialisée
XLA_FLAGS=--xla_gpu_dump_autotune_results_t=<myfile.pbtxt>
Exécuter une carte de compilateur unique
Les options de XLA_FLAGS sont également compatibles. L'outil peut donc être utilisé pour tester
en une seule passe:
$ hlo-opt --platform=CUDA --stage=hlo --xla-hlo-enable-passes-only=algebraic_simplifer input.hlo