Résumé technique : Caractérisation des bogues réels dans les programmes à tuiles pour la détection automatisée de bogues

Énoncé du problème

Les frameworks de programmation à base de tuiles (par exemple, Triton, TVM, Halide) sont de plus en plus adoptés pour générer des noyaux GPU haute performance destinés à l'apprentissage profond et au calcul scientifique. Ces frameworks abstraient les détails spécifiques au matériel en exprimant les calculs en termes de « tuiles » de taille fixe, déléguant au compilateur les décisions relatives à l'ordonnancement, à la disposition mémoire et à la synchronisation. Bien que cela améliore la productivité et la portabilité, cela introduit une classe distincte de bogues de génération de code (codegen).

Contrairement aux bogues de compilateur traditionnels où le programme d'entrée définit explicitement le flux de contrôle et l'accès à la mémoire, les compilateurs à tuiles doivent synthétiser ces éléments en fonction des formes de tuiles, des types de données et des cibles backend. Par conséquent, les bogues se manifestent souvent sous forme de problèmes de correction silencieux (par exemple, des résultats incorrects sans plantage) ou de dégradations de performance étroitement liées à des formes d'entrée spécifiques, des paramètres de tuiles ou des configurations backend. Les outils existants de test de compilateur (par exemple, Csmith, MLIR-Smith) et les méthodes de vérification GPU sont inadaptés à ce domaine car ils visent soit des IR génériques sans sémantique de tuiles, soit opèrent sur des noyaux bas niveau explicites (CUDA/OpenCL) plutôt que sur des abstractions au niveau des tuiles. De plus, l'absence d'implémentations de référence CPU pour de nombreux frameworks à tuiles complique la construction d'oracles. Malgré l'adoption croissante de ces systèmes, aucune étude systématique des causes racines, des symptômes et des correctifs des bogues réels de codegen à tuiles n'a été menée.

Méthodologie

Les auteurs ont mené une étude empirique systématique des bogues réels de codegen à tuiles selon le processus suivant :

1. Collecte de données :

   • Sélection des dépôts : Les auteurs ont identifié 15 dépôts open source actifs en utilisant des recherches de mots-clés composés (« langage à tuiles », « noyaux à tuiles », etc.) sur GitHub. Après filtrage pour l'activité, l'utilisation directe de tuiles et la pertinence sémantique, huit frameworks ont été sélectionnés pour analyse : OpenAI Triton, TileLang, Halide, TVM (composants à tuiles), XLA, DaCe, NVIDIA-Warps et PyTorch (modules spécifiques aux tuiles).
   • Extraction des bogues : De janvier 2022 à novembre 2025, les auteurs ont collecté des issues GitHub. Ils ont appliqué une stratégie de filtrage multi-étapes :
     1. Sélection des issues fermées/confirmées.
     2. Application de filtres par mots-clés et étiquettes (par exemple, « bogue à tuiles », « plantage de compilation », « mappage de warps »).
     3. Restriction aux issues avec des correctifs documentés (pull requests ou commits).
     4. Déduplication manuelle et suppression des rapports non pertinents (par exemple, demandes de fonctionnalités).
   • Jeu de données final : Ce processus a produit 401 rapports de bogues uniques.

2. Étiquetage et catégorisation :

   • Deux auteurs expérimentés ont examiné indépendamment les rapports pour attribuer des étiquettes de cause racine.
   • Les taxonomies traditionnelles (par exemple, bogues de synchronisation CUDA) se sont révélées insuffisantes. Les auteurs ont affiné la taxonomie pour refléter les modes de défaillance spécifiques aux tuiles, tels que les incohérences dans les limites des tuiles, la sémantique des identifiants de warp et les hypothèses de forme.
   • Corpus final : 100 rapports ont été exclus en raison d'informations insuffisantes ou d'erreurs utilisateur de haut niveau, aboutissant à un jeu de données curaté de 301 bogues de codegen de programmes à tuiles.

3. Analyse :

   • Les auteurs ont dérivé une taxonomie des causes racines, ont mappé les symptômes aux causes, ont analysé les motifs d'entrée déclenchant les bogues et ont catalogué les stratégies de réparation des développeurs.

Contributions clés

1. Un jeu de données curaté de 301 bogues réels

L'article fournit le premier jeu de données public de bogues de codegen à tuiles vérifiés à travers huit frameworks majeurs, soutenant la recherche empirique et les outils futurs.

2. Une taxonomie de causes racines en six catégories

L'étude classe les bogues en six catégories distinctes, détaillant leurs sous-catégories, symptômes et correctifs :

• Flux de contrôle et ordonnancement (5,32 %) : Bogues résultant d'une synthèse incorrecte des gardes de limite, des masques de prédicat ou de la synchronisation au niveau warp (par exemple, prédicats de bord de tuile incorrects, réordonnancement d'instructions violant les invariants de pipeline de tuiles).
• Construction et transformation IR (16,28 %) : Erreurs dans la génération d'IR conscients des tuiles (par exemple, création non déterministe de handles) ou leur réécriture (par exemple, suppression de tuiles de limite lors de l'optimisation).
• Mappage et lancement de tuiles (6,31 %) : Échecs dans le mappage des tuiles logiques à la géométrie d'exécution physique, incluant des dimensions de grille/bloc incorrectes ou des associations thread-tuile erronées.
• Bogues mémoire (19,27 %) : Problèmes dans la synthèse des calculs d'adresse, l'allocation de ressources (par exemple, libération prématurée de registres) ou l'ordonnancement/mise en cache (par exemple, lectures de données obsolètes dues à l'absence de barrières).
• Bogues de type et d'opérateur (48,84 %) : La catégorie la plus fréquente, impliquant la gestion des valeurs spéciales (NaN/Inf), la sémantique des types de données (perte de précision dans les opérations fusionnées) et les erreurs d'implémentation d'opérateurs (par exemple, logique de réduction incorrecte pour argmax sous tuilage).
• Bogues spécifiques au périphérique (3,99 %) : Incompatibilités entre le code généré et les contraintes matérielles spécifiques (par exemple, dimensions de tuiles ne s'alignant pas sur les dispositions d'atomes MMA).

3. Caractérisation de la manifestation et de la détection des bogues

• Symptômes : L'étude identifie que les plantages (58,14 %) sont le symptôme le plus courant, survenant souvent dans les étapes front-end ou back-end. Cependant, les problèmes de correction silencieux (résultats incorrects sans plantage) et les goulots d'étranglement de performance sont prévalents et plus difficiles à détecter.
• Motifs d'entrée : Les bogues émergent fréquemment dans des conditions d'entrée étroites, telles que des formes de tenseurs spécifiques (près des multiples de tuiles, étendues non divisibles), des dispositions spécifiques ou des valeurs extrêmes.
• Stratégies de détection : L'article propose un cadre pour la détection automatisée utilisant :
  • Génération d'entrées structurées : Ciblant les multiples de tuiles, les formes de limite et les types de précision mixte.
  • Stratégies multi-oracles : Dépassant le simple test différentiel pour inclure des oracles métamorphiques (par exemple, variation d'ordonnancement, remplissage/élagage), des vérifications de canari (valeurs sentinelles) et des invariants algébriques.

4. Stratégies de réparation et implications

Les auteurs ont analysé les motifs de correction, notant que :

• Les bogues de type et d'opérateur sont les cibles les plus fréquentes pour la réparation.
• Les correctifs nécessitent souvent un raisonnement global à travers les étapes de transformation (par exemple, ajustement des gardes de boucle, prédication et ordonnancement des instructions).
• La réparation des bogues de transformation IR exige une connaissance approfondie des représentations internes et des contraintes backend, augmentant la barrière pour les développeurs non-spécialistes en compilateurs.

Résultats et signification

L'article prétend être la première étude systématique des bogues de codegen de programmes à tuiles. Sa signification principale réside dans :

1. Définir un espace de bogues distinct : Il établit que les bogues de codegen à tuiles sont fondamentalement différents des bogues de compilateur traditionnels ou des bogues de noyaux CUDA en raison du rôle du compilateur dans la synthèse du flux de contrôle, de la disposition mémoire et de la synchronisation.
2. Guider le développement d'outils : Les résultats fournissent une base pour construire des outils de débogage, de test et de réparation dédiés, adaptés aux infrastructures de compilateurs à base de tuiles. Les auteurs soutiennent que les outils existants échouent car ils n'exercent pas systématiquement les transformations centrées sur les tuiles (par exemple, tuilage multi-niveaux, spécialisation de warp).
3. Informer la recherche future : En catégorisant les causes racines et en les mappant aux symptômes et correctifs, l'étude offre une feuille de route pour développer des flux de travail de détection automatisée tenant compte des bogues dépendants de la forme et de l'absence d'implémentations de référence CPU.

Les auteurs restent modestes, reconnaissant que leur jeu de données est limité par la maturité de l'écosystème à tuiles et que leurs résultats sont qualitatifs et exploratoires. Ils ne proposent pas un nouvel outil spécifique, mais fournissent plutôt la base empirique nécessaire pour que la communauté développe de tels outils.