LLVM debate compilar o ClangIR por omissão

Os programadores do LLVM debatem se o Clang deve compilar o ClangIR em todas as compilações. Erich Keane publicou uma RFC intitulada "Enable ClangIR Build By Default" a 6 de setembro de 2026 no fórum Discourse do LLVM. Tinha 34 respostas quando o Phoronix noticiou, no mesmo dia.

A proposta é mais estreita do que o título sugere. Compilar uma coisa lá dentro não é o mesmo que usá-la.

O que está mesmo a ser proposto

O ClangIR é uma nova representação intermédia para o Clang. Uma representação intermédia é a forma em que um compilador guarda o seu código entre analisá-lo e emitir instruções de máquina.

O Clang já tem uma, o LLVM IR. O ClangIR fica mais acima, mais perto da linguagem de origem, e assenta no MLIR. Ficar mais acima permite guardar informação que o LLVM IR deita fora, como de que construção de C++ veio um pedaço de código.

O código já está a montante. Apenas não faz parte da configuração de compilação por omissão, por isso a maioria de quem compila o Clang a partir do código não o recebe.

A RFC mudaria só isso. A geração de código continuaria a passar pelo caminho existente, a não ser que passe -fclangir explicitamente. Ninguém fica com o ClangIR por acidente.

As objeções

Três preocupações dominam o tópico, e nenhuma põe em causa a qualidade do ClangIR.

Preocupação	O problema
Tempo de compilação	Algumas estimativas apontam para mais do dobro
Falhas de plataforma	Os alvos da Microsoft e do Windows não são suportados
Custo de integração contínua	Cada máquina de teste paga a compilação mais longa, em cada execução

O número do tempo de compilação é o que faz estragos. Acrescentar o MLIR como dependência por omissão do Clang traz muito código que passariam a compilar todos os que compilam o Clang, incluindo quem nunca passará a opção.

Esse custo não é repartido por igual. Um responsável de distribuição que compila o Clang uma vez absorve-o sem custo. Um contribuidor que recompila localmente, ou uma frota de integração contínua que recompila a cada pull request, paga-o vezes sem conta.

Porque é que alguém o quer ligado

O argumento a favor é a adoção. Uma funcionalidade que ninguém compila é uma funcionalidade que ninguém testa. Manter o ClangIR fora da compilação por omissão significa que os erros só aparecem ao pequeno grupo que o liga, e só depois de o código já ter entrado.

Ligá-lo por omissão torna-o parte normal da árvore. As quebras aparecem na integração contínua vulgar em vez de num bot especializado, e é assim que um projeto impede que um componente experimental apodreça em silêncio.

Nada está decidido. É uma RFC com um tópico ativo, e a discussão é sobre custo, não sobre direção.

O que isto significa para programadores

Se compila o Clang a partir do código, siga o tópico mais do que o desfecho. O que está a ser negociado são os seus tempos de compilação, e os números do tópico são estimativas. Medir a sua própria compilação com o MLIR incluído é melhor base para planear do que um número de uma mensagem de fórum.

Se gere uma integração contínua que compila o LLVM, faça as contas agora. Um dobro aplicado a cada pull request é uma rubrica de orçamento, não um incómodo, e chega com a versão que primeiro levar a mudança.

Se trabalha em cadeias de ferramentas para Windows, é a sua deixa para falar. A RFC nomeia a ausência de suporte aos alvos da Microsoft como um bloqueio, e é nos tópicos de RFC que isso é pesado. Os projetos de código aberto têm vindo a formalizar decisões destas, desde o processo RFC que a GNOME está a redigir até a votação da Debian sobre contribuições assistidas por IA.

E se apenas usa o Clang a partir de um gestor de pacotes, isto ainda não muda nada. Teria um binário de compilador um pouco maior e uma opção extra que pode ignorar.