LLVM debate compilar ClangIR por defecto

Los desarrolladores de LLVM debaten si Clang debería compilar ClangIR en cada build. Erich Keane publicó una RFC titulada "Enable ClangIR Build By Default" el 6 de septiembre de 2026 en el foro Discourse de LLVM. Tenía 34 respuestas cuando Phoronix lo contó, ese mismo día.

La propuesta es más estrecha de lo que sugiere el titular. Compilar algo dentro no es lo mismo que usarlo.

Qué se propone en realidad

ClangIR es una nueva representación intermedia para Clang. Una representación intermedia es la forma en que un compilador guarda tu código entre analizarlo y emitir instrucciones de máquina.

Clang ya tiene una, LLVM IR. ClangIR está más arriba, más cerca del lenguaje de origen, y se apoya en MLIR. Estar más arriba permite conservar información que LLVM IR descarta, como de qué construcción de C++ venía un fragmento de código.

El código ya está upstream. Simplemente no forma parte de la configuración de compilación por defecto, así que la mayoría de quienes compilan Clang desde las fuentes no lo obtienen.

La RFC cambiaría solo eso. La generación de código seguiría yendo por la ruta existente salvo que pases -fclangir de forma explícita. Nadie obtiene ClangIR por accidente.

Las objeciones

Tres preocupaciones dominan el hilo, y ninguna cuestiona la calidad de ClangIR.

Preocupación	El problema
Tiempo de compilación	Algunas estimaciones lo doblan con creces
Huecos de plataforma	Los objetivos de Microsoft y Windows no están soportados
Coste de integración continua	Cada máquina de pruebas paga la compilación más larga, en cada ejecución

La cifra del tiempo de compilación es la que hace daño. Añadir MLIR como dependencia por defecto de Clang arrastra una gran cantidad de código que compilarían entonces todos los que compilan Clang, incluidos quienes nunca pasarán el indicador.

Ese coste no se reparte igual. Un mantenedor de distribución que compila Clang una vez lo absorbe sin problema. Un colaborador que recompila en local, o una flota de integración continua que recompila en cada pull request, lo paga una y otra vez.

Por qué alguien lo quiere activado

El argumento a favor es la adopción. Una función que nadie compila es una función que nadie prueba. Dejar ClangIR fuera de la compilación por defecto significa que los fallos aparecen solo para el grupo pequeño que lo activa, y solo después de que el código ya ha entrado.

Activarlo por defecto lo convierte en parte normal del árbol. Las roturas salen en la integración continua corriente y no en un bot especializado, que es como un proyecto evita que un componente experimental se pudra en silencio.

No hay nada decidido. Es una RFC con un hilo activo, y la discusión va de coste, no de dirección.

Qué significa esto para los desarrolladores

Si compilas Clang desde las fuentes, sigue el hilo más que el desenlace. Lo que se está negociando son tus tiempos de compilación, y las cifras del hilo son estimaciones. Medir tu propia compilación con MLIR incluido es mejor base para planificar que un número de un mensaje de foro.

Si operas una integración continua que compila LLVM, calcula el coste ahora. Un doblado aplicado a cada pull request es una partida de presupuesto, no una molestia, y llega con la versión que lleve el cambio por primera vez.

Si trabajas en cadenas de herramientas de Windows, es tu momento de hablar. La RFC nombra la falta de soporte de objetivos de Microsoft como un bloqueante, y los hilos de RFC son donde eso se pondera. Los proyectos de código abierto llevan tiempo formalizando decisiones así, desde el proceso RFC que redacta GNOME hasta la votación de Debian sobre contribuciones asistidas por IA.

Y si solo usas Clang desde un gestor de paquetes, esto no cambia nada todavía. Tendrías un binario de compilador algo mayor y un indicador extra que puedes ignorar.