Por qué Clang triplicó el rendimiento de un validador UTF-8 y GCC no

El autor, Nemanja Trifunović, mantiene desde 2006 una biblioteca C++ de código abierto para manejar cadenas UTF-8 y recientemente reoptimizó su función validate_next, que decodifica un code point UTF-8 a partir de un iterador de bytes. La versión original determina la longitud de la secuencia según el byte inicial, obtiene los bytes de continuación y, tras decodificar, aplica dos comprobaciones de seguridad: validez del code point y detección de secuencias overlong. La optimización aprovecha que todo carácter ASCII (byte con el bit alto a cero, rango U+0000–U+007F) cumple automáticamente la validez UTF-8, por lo que basta con extenderlo con ceros: en cuanto la ruta detecta longitud 1, devuelve el resultado sin pasar por las validaciones posteriores. Probado con Clang 18.1.3, el rendimiento se triplicó para texto ASCII puro y mejoró alrededor del 34 % en texto mixto. Sorprendentemente, al repetir las pruebas con GCC no se observó ninguna mejora en ASCII: el ensamblado muestra que GCC ya deduce que las comprobaciones son tautológicas en la rama ASCII y las elimina automáticamente. Clang, en cambio, no las elimina y conserva las comprobaciones de validez, de ahí el gran salto al introducirlas manualmente. Para texto muy mixto, GCC rindió un 3-4 % peor con el cambio. La conclusión práctica es que el mismo código fuente puede generar ensamblados muy distintos según el compilador, y que las microoptimizaciones han de validarse con ambas toolchains.