SIL: leer la representación intermedia de Swift

El código fuente de Swift está diseñado para que no veas el trabajo: una asignación oculta una copia, una llamada a método oculta una consulta de tabla, un cierre oculta una asignación en el montón y una suma oculta una comprobación de desbordamiento. SIL es la representación donde todo eso está escrito, instrucción por instrucción, en una forma que el compilador puede verificar. Aprender a leerlo no es un ejercicio de arqueología: es la única manera de sustituir la creencia sobre lo que cuesta tu código por la observación directa de lo que el compilador realmente emitió.

Por qué SIL no se parece al fuente

SIL está en forma de asignación única estática: cada valor se define exactamente una vez y nunca se reasigna. Lo que en el fuente era una variable mutada en un bucle aquí es una cadena de valores distintos. En lugar de las funciones de confluencia clásicas de otras representaciones, Swift usa argumentos de bloque: un bloque básico declara parámetros y cada salto le pasa los valores correspondientes, lo cual hace el grafo más simple de transformar.

La segunda diferencia es que SIL conserva los tipos de Swift, no los de la máquina, y añade una distinción esencial. Un tipo escrito como valor directo indica un valor de objeto, cargado y manipulado como tal; el mismo tipo precedido de asterisco indica una dirección, un lugar en memoria sobre el que se opera con carga, almacenamiento y destrucción. Esa distinción es lo que permite manejar tipos cuyo tamaño no se conoce al compilar.

La tercera es la propiedad explícita. En la forma con propiedad, cada valor tiene un dueño conocido y su ciclo de vida está delimitado por instrucciones concretas: se copia con una instrucción, se destruye con otra, se presta con un par de marcas de inicio y fin. El verificador rechaza cualquier función donde un valor se use tras destruirse o se abandone sin destruir. La gestión de memoria deja de ser una convención y pasa a ser una propiedad demostrable.

Anatomía de una función

Una función en SIL empieza por una declaración con su visibilidad, sus atributos, su nombre decorado y su tipo, que incluye la convención de llamada de cada parámetro: si llega prestado, si llega en propiedad, si llega por dirección de entrada, de salida o de entrada y salida. Después vienen los bloques.

// Fuente
func doble(_ n: Int) -> Int { n + n }

// SIL canonico, simplificado y anotado
// sil hidden [ossa] @$s4Demo5dobleyS2iF : $@convention(thin) (Int) -> Int {
// bb0(%0 : $Int):                              // argumento de bloque, valor de objeto
//   %1 = struct_extract %0 : $Int, #Int._value  // saca el entero primitivo del struct
//   %2 = builtin "sadd_with_overflow_Int64"(%1, %1, ...) // suma con bandera
//   %3 = tuple_extract %2, 0                   // el resultado
//   %4 = tuple_extract %2, 1                   // hubo desbordamiento
//   cond_fail %4, "arithmetic overflow"        // la trampa que el fuente no muestra
//   %5 = struct $Int (%3)                      // vuelve a envolverse en Int
//   return %5 : $Int
// }

Dos lecturas inmediatas. La primera: Int no es un entero primitivo sino un struct de un campo, y el compilador lo desenvuelve y lo vuelve a envolver sin coste alguno. La segunda: la suma de Swift incluye una comprobación de desbordamiento con una instrucción de trampa asociada, que es exactamente la diferencia con la aritmética envolvente y el motivo por el que existe una familia de operadores alternativos.

Qué buscar en un volcado

Un volcado real es largo, y leerlo entero es una pérdida de tiempo. Lo productivo es buscar familias concretas de instrucciones, porque cada familia responde a una pregunta de rendimiento distinta.

• Despacho. Una referencia a función seguida de una aplicación es una llamada directa, candidata a insertarse en línea. Una consulta de método de clase indica despacho por tabla virtual; una consulta de método de testigo indica despacho por protocolo. Ver una de estas dos en un bucle caliente es la señal de que la desvirtualización no ocurrió.
• Memoria. Las instrucciones de reserva de caja o de referencia son asignaciones en el montón. Una caja en una función que no debería asignar suele delatar una captura que escapa o un existencial que no cupo en línea.
• Propiedad. Las copias y destrucciones de valor, o las retenciones y liberaciones en la forma sin propiedad, son el tráfico de conteo de referencias. Contarlas en el cuerpo de un bucle es la medida más directa del coste que impone la gestión automática de memoria.
• Existenciales y genéricos. Las instrucciones de inicialización de existencial revelan un borrado de tipo; los nombres decorados que anuncian una versión especializada revelan que el optimizador clonó el genérico para un tipo concreto.
• Trampas. Las instrucciones de fallo condicional son comprobaciones de límites, de desbordamiento o de conversión. Su ausencia tras optimizar demuestra que el compilador probó que eran innecesarias.

flowchart TB
A[Volcado de SIL de una funcion] --> B{Que pregunta quieres responder}
B -->|Coste de llamada| C[Buscar function ref y apply frente a class method o witness method]
B -->|Coste de memoria| D[Buscar alloc box y alloc ref]
B -->|Coste de ARC| E[Buscar copy value y destroy value]
B -->|Abstraccion borrada| F[Buscar init existential y nombres con specialized]
B -->|Comprobaciones| G[Buscar cond fail]
C --> H[Conclusion sobre despacho e insercion en linea]
D --> H
E --> H
F --> H
G --> H
style H fill:#a6e3a1,color:#11111b
style B fill:#89b4fa,color:#11111b

# SIL en bruto: lo mas cercano al fuente, util para entender la bajada
swiftc -emit-silgen Fuente.swift | swift demangle > bruto.sil

# SIL canonico sin optimizar y SIL tras el pipeline de optimizacion
swiftc -Onone -emit-sil Fuente.swift | swift demangle > canonico.sil
swiftc -O     -emit-sil Fuente.swift | swift demangle > optimizado.sil

# Aislar una sola funcion en lugar de leer el modulo entero
swiftc -O -emit-sil -Xllvm -sil-print-function=doble Fuente.swift

# Contar el trafico de conteo de referencias de un cuerpo concreto
grep -cE "copy_value|destroy_value|strong_retain|strong_release" optimizado.sil

Un caso completo: el existencial frente al genérico

La utilidad de leer SIL se aprecia mejor sobre dos funciones que hacen exactamente lo mismo y que el fuente presenta como casi idénticas.

protocol Figura { var area: Double { get } }
struct Circulo: Figura { let r: Double; var area: Double { 3.14159 * r * r } }

func sumarCaja(_ xs: [any Figura]) -> Double {
    xs.reduce(0) { $0 + $1.area }
}

func sumarGen<F: Figura>(_ xs: [F]) -> Double {
    xs.reduce(0) { $0 + $1.area }
}

En el volcado optimizado del primero encuentras, dentro del bucle, una consulta de método de testigo por elemento, una apertura de existencial para acceder al valor guardado y tráfico de conteo de referencias asociado a la caja del montón cuando el valor no cabía en línea. Ninguna de esas instrucciones puede eliminarse, porque el tipo dinámico se decide en ejecución y no hay nada sobre lo que razonar.

En el volcado del segundo encuentras una función clonada cuyo nombre decorado menciona el tipo concreto, la llamada al cálculo del área insertada en línea, la aritmética expuesta como operaciones primitivas y ni una sola instrucción de propiedad. El bucle es candidato a desenrollado y a vectorización, y en muchos casos el compilador ya lo hizo.

# La comparacion que cierra la discusion en treinta segundos
swiftc -O -emit-sil Figuras.swift | swift demangle > opt.sil
grep -c "witness_method" opt.sil        # despacho dinamico superviviente
grep -c "open_existential" opt.sil      # aperturas de caja
grep -c "specialized"     opt.sil       # clones generados

Eso es lo que significa leer SIL con propósito: no admirar la representación intermedia, sino convertir una discusión de opiniones sobre diseño en tres números que cualquiera puede reproducir.