El incidente se manifestó como una degradación inesperada del rendimiento al compilar código Lua con el compilador antcc en el nivel de optimización -O2. Aunque se esperaba una mejora, el código resultante era hasta 1.4 veces más lento. La investigación inicial apuntó a la optimización de inlining, que, si bien es generalmente beneficiosa, parecía estar causando un aumento excesivo del tamaño del código en la función crítica luaV_execute, el bucle principal del intérprete de Lua.
El análisis profundo reveló que el problema no era directamente el tamaño del código generado por el inlining, sino una interacción patológica entre el inlining, la fase de Static Single-Assignment (SSA) mem2reg y el asignador de registros. Específicamente, el inlining de pequeñas funciones dentro de luaV_execute introducía variables locales que, debido a una implementación incorrecta de mem2reg, eran tratadas como si tuvieran un alcance de vida que abarcaba todo el bucle del intérprete. Esto se manifestaba en la generación de múltiples 'phi functions' en el encabezado del bucle, que mantenían estas variables 'live' a través de todas las iteraciones.
La presencia de estas 'phi functions' innecesarias generó una presión de registros extrema. El asignador de registros, que utiliza un algoritmo de 'linear scan' básico, no pudo asignar todas las variables a registros físicos, lo que resultó en un 'spilling' masivo al stack. Más del 40% de las instrucciones en el código ensamblador final eran movimientos de datos entre el stack y los registros, lo que explica el aumento de 2.4x en el tamaño binario y la consecuente degradación del rendimiento debido a la sobrecarga de memoria y la penalización de la caché. La salvaguarda falló porque la lógica de mem2reg no distinguía correctamente el alcance de las variables locales dentro de los bucles en el contexto de SSA.