Niveles de optimización en C y el impacto del UB

Los niveles de optimización son instrucciones para el backend del compilador (como el generador de código de GCC o Clang) que determinan cuánto esfuerzo debe realizar para transformar tu código fuente en un binario eficiente. No se trata solo de “hacerlo más rápido”, sino de un compromiso técnico entre el tiempo de compilación, el tamaño del binario y la velocidad de ejecución.

Cuando compilas, el compilador analiza tu código para aplicar transformaciones como el inlining (reemplazar una llamada a función por el cuerpo de la misma), la eliminación de código muerto (borrar instrucciones que no afectan el resultado final) o el unrolling de bucles.

¿Por qué existen distintos niveles? Porque cada optimización tiene un coste. Por ejemplo, una optimización agresiva puede hacer que el binario sea más grande, lo que paradójicamente podría ralentizar la ejecución debido a una mayor presión en la cache de instrucciones (L1i). ¿Cuándo deberías usar cada uno? -O2 es el estándar de oro para producción: ofrece un equilibrio excelente entre velocidad y tamaño. -O3 es para algoritmos críticos donde la vectorización (uso de instrucciones SIMD) es vital. -Os es tu mejor aliado en sistemas embebidos donde cada byte cuenta, y -O0 es indispensable cuando necesitas depurar con gdb, ya que mantiene una correspondencia 1:1 entre el código fuente y las instrucciones de máquina.

Si te equivocas en la lógica de tu programa —específicamente si introduces comportamiento indefinido (UB)—, las optimizaciones pueden convertir un código que “parece” funcionar en -O0 en un programa que se comporta de forma errática o que simplemente elimina bloques de código enteros en -O2 o -O3. El compilador asume que el programador ha respetado las reglas del estándar C; si las rompes, el optimizador usará esa suposición para “limpiar” tu código de forma impredecible.

#include <stdio.h>
#include <stdlib.h>

/* 
 * La palabra clave 'restrict' [C99] es una promesa al compilador:
 * "Para este ciclo, el puntero 'src' no se solapará con 'dest'".
 * Esto permite al compilador usar instrucciones SIMD para procesar
 * múltiples datos simultáneamente sin miedo a que una escritura
 * altere una lectura pendiente.
 */
void process_data(const float *restrict src, float *restrict dest, size_t n) {
    for (size_t i = 0; i < n; ++i) {
        dest[i] = src[i] * 2.5f;
    }
}

int main(void) {
    size_t n = 1000000;
    float *src = malloc(n * sizeof(float));
    float *dest = malloc(n * sizeof(float));

    if (!src || !dest) {
        free(src);
        free(dest);
        return 1;
    }

    // Inicialización de datos
    for (size_t i = 0; i < n; ++i) {
        src[i] = (float)i;
    }

    process_data(src, dest, n);

    // Verificación simple de la suma de los resultados
    double sum = 0;
    for (size_t i = 0; i < n; ++i) {
        sum += (double)dest[i];
    }

    printf("Suma total: %.2f\n", sum);

    free(src);
    free(dest);
    return 0;
}

Análisis del comportamiento

Fíjate en la función process_data. Lo que ocurre bajo el capó cambia drásticamente según la bandera que elijas:

1. En -O0: El compilador generará un bucle simple. Por cada iteración, cargará src[i] en un registro, multiplicará por 2.5f y guardará el resultado en dest[i]. Es código predecible, pero lento.
2. En -O2: El compilador aplicará inlining si la función es pequeña y reordenará las instrucciones para evitar esperas de la CPU (pipeline stalls). El código será mucho más eficiente pero la estructura seguirá siendo similar.
3. En -O3: Aquí es donde ocurre la magia de la vectorización automática. El compilador detecta que el bucle es independiente y que src y dest no se solapan (gracias al restrict). En lugar de procesar un float a la vez, usará registros de 256 o 512 bits (como AVX) para procesar 8 o 16 floats en una sola instrucción.
4. En -Os: El compilador evitará el unrolling de bucles y la vectorización agresiva si esto aumenta demasiado el tamaño del binario, priorizando la densidad del código para ahorrar memoria.

Un detalle crítico es -ffast-math. Esta bandera permite al compilador ignorar las reglas estrictas del estándar IEEE 754 (como la propagación de NaNs o la precisión en operaciones de punto flotante) para ganar velocidad. Es extremadamente peligrosa porque permite que el compilador reordene operaciones como (a + b) + c a a + (b + c), lo cual puede cambiar el resultado debido al error de redondeo.

El error frecuente

Un error clásico que solo se manifiesta en niveles de optimización altos es la violación de la restricción restrict. Si intentas usar process_data pasando buffers que se solapan, como:

float datos[100];
process_data(datos, &datos[1], 100); // ERROR: UB por solapamiento

En -O0, esto podría “funcionar” por pura suerte. Pero en -O3, el compilador, creyendo ciegamente en tu promesa de restrict, utilizará instrucciones vectorizadas que cargan bloques grandes de memoria. Al hacerlo, las escrituras de un bloque sobrescribirán los datos que aún deben ser leídos del siguiente, corrompiendo el cálculo de forma silenciosa. AddressSanitizer (ASan) es fundamental para detectar estos problemas de solapamiento que el compilador simplemente ignorará.

N° 6