Optimización del asignador bump de LLVM: tres cambios para acelerar la ruta rápida

BumpPtrAllocator es el asignador bump (de tipo arena) de LLVM: cada asignación avanza un puntero dentro de un slab y todo se libera de golpe al destruir el asignador. Da soporte a áreas críticas como el ASTContext de Clang, los pools de objetos make de lld y los registros de TableGen. Una optimización reciente ha reformado su ruta rápida mediante tres cambios coordinados en el proyecto LLVM. El primero (#205240) sustituye la realineación genérica por una verificación de alineación mínima: un puntero recién avanzado suele estar ya alineado, así que solo se realinea cuando se piden alineaciones superiores a MinAlign (8 por defecto, 1 en SpecificBumpPtrAllocator). El segundo (#205485) elimina la comprobación explícita de nulo almacenando el final como un centinela (EndSentinel = realEnd + 1, o 0 si no hay slab), de modo que un asignador vacío cae por la ruta lenta con una sola comparación sin signo. El tercero (#205711) suprime el contador BytesAllocated, que solo servía a diagnósticos y estadísticas como el informe de memoria de ConstString en lldb o el dumpAllocationStats de TableGen. En conjunto, la ruta rápida queda en seis instrucciones de ensamblador. Las mediciones del Compile-Time Tracker muestran mejoras significativas en compilaciones stage2 (−0,14 % en instrucciones en O3 y −0,36 % en O0-g, con reducciones también en RSS), mientras que en stage1 el efecto es menor (−0,04 % en O3). El artículo también recuerda la precaución con la zona roja de ASan, que no debe condicionarse a LLVM_ADDRESS_SANITIZER_BUILD (es por unidad de traducción) sino a LLVM_ENABLE_ABI_BREAKING_CHECKS, que es fijo por build de biblioteca y se aplica en tiempo de enlace. La principal lección es que en un bump allocator el coste real no está en el trabajo útil sino en la realineación y la contabilidad; además, una mejora puede manifestarse como redistribución de tamaño y no como una contracción uniforme.