LLVM debattiert, ClangIR standardmäßig zu bauen

LLVM-Entwickler debattieren, ob Clang ClangIR in jeden Build kompilieren sollte. Erich Keane stellte einen RFC mit dem Titel "Enable ClangIR Build By Default" am 6. September 2026 ins LLVM-Discourse-Forum. Bis Phoronix darüber berichtete, noch am selben Tag, hatte er 34 Antworten.

Der Vorschlag ist enger, als die Überschrift nahelegt. Etwas mitzubauen ist nicht dasselbe, wie es zu benutzen.

Was tatsächlich vorgeschlagen wird

ClangIR ist eine neue Zwischendarstellung für Clang. Eine Zwischendarstellung ist die Form, in der ein Compiler Ihren Code zwischen dem Parsen und dem Erzeugen von Maschinenbefehlen hält.

Clang hat bereits eine, LLVM IR. ClangIR sitzt höher, näher an der Ausgangssprache, und baut auf MLIR auf. Höher zu sitzen heißt, Informationen behalten zu können, die LLVM IR verwirft, etwa aus welchem C++-Konstrukt ein Codestück stammt.

Der Code ist bereits upstream. Er gehört nur nicht zur Standard-Build-Konfiguration, sodass die meisten, die Clang aus dem Quellcode bauen, ihn nicht bekommen.

Der RFC würde genau das ändern. Die Codeerzeugung liefe weiterhin über den bestehenden Pfad, sofern man nicht ausdrücklich -fclangir übergibt. Niemand bekommt ClangIR aus Versehen.

Die Einwände

Drei Bedenken prägen den Thread, und keines betrifft die Qualität von ClangIR.

Bedenken	Das Problem
Bauzeit	Manche Schätzungen sehen die Bauzeiten mehr als verdoppelt
Plattformlücken	Microsoft- und Windows-Ziele werden nicht unterstützt
CI-Kosten	Jede Testmaschine zahlt den längeren Build, bei jedem Lauf

Die Zahl zur Bauzeit richtet den Schaden an. MLIR als Standardabhängigkeit von Clang zieht viel Code herein, den dann alle mitkompilieren, die Clang bauen, auch jene, die das Flag nie übergeben werden.

Diese Kosten verteilen sich ungleich. Wer als Distributions-Maintainer Clang einmal baut, verkraftet sie leicht. Wer lokal beiträgt oder eine CI-Flotte bei jedem Pull Request neu bauen lässt, zahlt sie wieder und wieder.

Warum manche es trotzdem wollen

Das Argument dafür heißt Verbreitung. Was niemand kompiliert, testet auch niemand. ClangIR aus dem Standard-Build herauszuhalten bedeutet, dass Fehler nur der kleinen Gruppe auffallen, die es einschaltet, und erst nachdem der Code bereits gelandet ist.

Standardmäßig eingeschaltet wird es zu einem normalen Teil des Baums. Brüche zeigen sich in der gewöhnlichen CI statt auf einem Spezial-Bot, und genau so verhindert ein Projekt, dass eine experimentelle Komponente still vor sich hin verrottet.

Entschieden ist nichts. Es ist ein RFC mit einem aktiven Thread, und die Diskussion dreht sich um Kosten, nicht um die Richtung.

Was das für Entwickler bedeutet

Wer Clang aus dem Quellcode baut, verfolgt besser den Thread als das Ergebnis. Ihre Bauzeiten sind das, was hier gehandelt wird, und die Zahlen im Thread sind Schätzungen. Den eigenen Build einmal mit MLIR zu messen ist eine bessere Planungsgrundlage als eine Zahl aus einem Forumsbeitrag.

Wer eine CI betreibt, die LLVM kompiliert, sollte das jetzt durchrechnen. Eine Verdopplung bei jedem Pull Request ist ein Budgetposten, keine Unannehmlichkeit, und sie kommt mit dem Release, das die Änderung zuerst trägt.

Wer an Windows-Toolchains arbeitet, sollte sich zu Wort melden. Der RFC nennt die fehlende Unterstützung für Microsoft-Ziele als Blocker, und in RFC-Threads wird so etwas gewichtet. Open-Source-Projekte formalisieren solche Entscheidungen zuletzt häufiger, von GNOMEs Entwurf eines RFC-Prozesses bis zu Debians Abstimmung über KI-gestützte Beiträge.

Und wer Clang einfach aus einem Paketmanager nutzt, für den ändert sich vorerst nichts. Sie bekämen eine etwas größere Compiler-Binärdatei und ein zusätzliches Flag, das Sie ignorieren können.