LLVM débat de compiler ClangIR par défaut

Les développeurs de LLVM débattent de compiler ClangIR dans chaque build de Clang. Erich Keane a publié une RFC intitulée "Enable ClangIR Build By Default" le 6 septembre 2026 sur le forum Discourse de LLVM. Elle comptait 34 réponses au moment où Phoronix l'a rapportée, le même jour.

La proposition est plus étroite que le titre ne le laisse croire. Compiler quelque chose n'est pas l'utiliser.

Ce qui est réellement proposé

ClangIR est une nouvelle représentation intermédiaire pour Clang. Une représentation intermédiaire est la forme sous laquelle un compilateur conserve votre code entre l'analyse et l'émission des instructions machine.

Clang en a déjà une, LLVM IR. ClangIR se situe plus haut, plus près du langage source, et repose sur MLIR. Être plus haut permet de garder des informations que LLVM IR jette, comme la construction C++ dont vient un morceau de code.

Le code est déjà en amont. Il ne fait simplement pas partie de la configuration de compilation par défaut, donc la plupart des gens qui compilent Clang depuis les sources ne l'obtiennent pas.

La RFC ne changerait que cela. La génération de code passerait toujours par le chemin existant, sauf à passer explicitement -fclangir. Personne n'obtient ClangIR par accident.

Les objections

Trois inquiétudes dominent le fil, et aucune ne porte sur la qualité de ClangIR.

Inquiétude	Le problème
Temps de compilation	Des estimations parlent de plus du double
Lacunes de plateforme	Les cibles Microsoft et Windows ne sont pas prises en charge
Coût d'intégration continue	Chaque machine de test paie la compilation plus longue, à chaque exécution

Le chiffre du temps de compilation fait le dégât. Ajouter MLIR comme dépendance par défaut de Clang tire une grande quantité de code que compileraient alors tous ceux qui compilent Clang, y compris ceux qui ne passeront jamais le drapeau.

Ce coût n'est pas partagé équitablement. Un mainteneur de distribution qui compile Clang une fois l'absorbe sans peine. Un contributeur qui recompile localement, ou une flotte d'intégration continue qui recompile à chaque pull request, le paie encore et encore.

Pourquoi certains y tiennent

L'argument pour est l'adoption. Une fonctionnalité que personne ne compile est une fonctionnalité que personne ne teste. Garder ClangIR hors de la compilation par défaut signifie que les bogues n'apparaissent que pour le petit groupe qui l'active, et seulement après que le code a atterri.

L'activer par défaut en fait une partie normale de l'arbre. Les casses apparaissent dans l'intégration continue ordinaire plutôt que sur un robot spécialisé, et c'est ainsi qu'un projet empêche un composant expérimental de pourrir en silence.

Rien n'est décidé. C'est une RFC avec un fil actif, et la discussion porte sur le coût, pas sur la direction.

Ce que cela signifie pour les développeurs

Si vous compilez Clang depuis les sources, suivez le fil plutôt que le résultat. Ce sont vos temps de compilation qui se négocient, et les chiffres du fil sont des estimations. Mesurer votre propre compilation avec MLIR inclus vaut mieux qu'un chiffre tiré d'un message de forum.

Si vous exploitez une intégration continue qui compile LLVM, chiffrez cela maintenant. Un doublement appliqué à chaque pull request est une ligne de budget, pas un désagrément, et il arrive avec la version qui portera le changement en premier.

Si vous travaillez sur les chaînes d'outils Windows, c'est le moment de parler. La RFC nomme l'absence de prise en charge des cibles Microsoft comme un bloqueur, et c'est dans les fils de RFC que cela se pèse. Les projets open source formalisent de plus en plus ce genre de décision, du processus RFC que rédige GNOME au vote de Debian sur les contributions assistées par IA.

Et si vous utilisez simplement Clang depuis un gestionnaire de paquets, cela ne change rien pour l'instant. Vous auriez un binaire de compilateur un peu plus gros et un drapeau supplémentaire que vous pouvez ignorer.