c++ - Comportamiento inconsistente de la optimización del compilador de la cadena no utilizada

gcc compilation

Question

Tengo curiosidad por qué el siguiente código:

#include <string>
int main()
{
std::string a = "ABCDEFGHIJKLMNO";
}

Cuando se compila con -O3 obtiene el siguiente código:

main: # @main
xor eax, eax
ret

(Entiendo perfectamente que no hay necesidad de usar a no utilizado, a lo que el compilador puede omitirlo completamente del código generado)

Sin embargo el siguiente programa:

#include <string>
int main()
{
std::string a = "ABCDEFGHIJKLMNOP"; // <-- !!! One Extra P
}

rendimientos

main: # @main
push rbx
sub rsp, 48
lea rbx, [rsp + 32]
mov qword ptr [rsp + 16], rbx
mov qword ptr [rsp + 8], 16
lea rdi, [rsp + 16]
lea rsi, [rsp + 8]
xor edx, edx
call std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_create(unsigned long&, unsigned long)
mov qword ptr [rsp + 16], rax
mov rcx, qword ptr [rsp + 8]
mov qword ptr [rsp + 32], rcx
movups xmm0, xmmword ptr [rip + .L.str]
movups xmmword ptr [rax], xmm0
mov qword ptr [rsp + 24], rcx
mov rax, qword ptr [rsp + 16]
mov byte ptr [rax + rcx], 0
mov rdi, qword ptr [rsp + 16]
cmp rdi, rbx
je .LBB0_3
call operator delete(void*)
.LBB0_3:
xor eax, eax
add rsp, 48
pop rbx
ret
mov rdi, rax
call _Unwind_Resume
.L.str:
.asciz "ABCDEFGHIJKLMNOP"

Cuando se compila con el mismo -O3 . No entiendo por qué no reconoce que la a todavía no se usa, independientemente de que la cadena sea un byte más larga.

Esta pregunta es relevante para gcc 9.1 y clang 8.0, (en línea: https://gcc.godbolt.org/z/p1Z8Ns ) porque otros compiladores en mi observación descartan por completo la variable no utilizada (ellcc) o generan código para ella independientemente de la longitud de la cadena.

Answer 1

Esto se debe a la pequeña optimización de cadenas. Cuando los datos de la cadena tienen menos de o 16 caracteres, incluido el terminador nulo, se almacenan en un búfer local para el objeto std::string sí. De lo contrario, asigna memoria en el montón y almacena los datos allí.

La primera cadena "ABCDEFGHIJKLMNO" más el terminador nulo es exactamente del tamaño 16. Agregar "P" hace que exceda el búfer, por lo que se llama internamente a la new , lo que inevitablemente conduce a una llamada al sistema. El compilador puede optimizar algo si es posible asegurarse de que no haya efectos secundarios. Probablemente, una llamada al sistema hace que sea imposible hacer esto; por contraposición, el cambio de un búfer local al objeto en construcción permite tal análisis de efectos secundarios.

El rastreo del búfer local en libstdc ++, versión 9.1, revela estas partes de bits/basic_string.h :

template<typename _CharT, typename _Traits, typename _Alloc>
class basic_string
{
// ...
enum { _S_local_capacity = 15 / sizeof(_CharT) };
union
{
_CharT _M_local_buf[_S_local_capacity + 1];
size_type _M_allocated_capacity;
};
// ...
};

que le permite detectar el tamaño del búfer local _S_local_capacity y el búfer local ( _M_local_buf ). Cuando el constructor activa basic_string::_M_construct se llama, tiene en bits/basic_string.tcc :

void _M_construct(_InIterator __beg, _InIterator __end, ...)
{
size_type __len = 0;
size_type __capacity = size_type(_S_local_capacity);
while (__beg != __end && __len < __capacity)
{
_M_data()[__len++] = *__beg;
++__beg;
}

donde el buffer local se llena con su contenido. Justo después de esta parte, llegamos a la rama donde se ha agotado la capacidad local: se asigna un nuevo almacenamiento (a través de la asignación en M_create ), el búfer local se copia en el nuevo almacenamiento y se llena con el resto del argumento de inicialización:

 while (__beg != __end)
{
if (__len == __capacity)
{
// Allocate more space.
__capacity = __len + 1;
pointer __another = _M_create(__capacity, __len);
this->_S_copy(__another, _M_data(), __len);
_M_dispose();
_M_data(__another);
_M_capacity(__capacity);
}
_M_data()[__len++] = *__beg;
++__beg;
}

Como nota al margen, la optimización de cadenas pequeñas es un tema por sí solo. Para tener una idea de cómo ajustar los bits individuales puede hacer una diferencia a gran escala, recomiendo esta charla . También menciona cómo la implementación std::string que viene con gcc (libstdc ++) funciona y cambió en el pasado para que coincida con las versiones más nuevas del estándar.

Answer 2

Me sorprendió que el compilador viera a través de un par std::string constructor / destructor hasta que vi su segundo ejemplo. No lo hizo Lo que está viendo aquí es la optimización de cadenas pequeñas y las optimizaciones correspondientes del compilador en torno a eso.

Las optimizaciones de cadenas pequeñas se producen cuando el propio objeto std::string es lo suficientemente grande como para contener el contenido de la cadena, un tamaño y posiblemente un bit de discriminación utilizado para indicar si la cadena está funcionando en modo de cadena pequeña o grande. En tal caso, no se producen asignaciones dinámicas y la cadena se almacena en el propio objeto std::string .

Los compiladores son realmente malos en eludir asignaciones y desasignaciones innecesarias, son tratados casi como si tuvieran efectos secundarios y, por lo tanto, son imposibles de eludir. Cuando supera el umbral de optimización de cadena pequeña, se producen asignaciones dinámicas y el resultado es lo que ve.

Como ejemplo

void foo() {
delete new int;
}

es el par de asignación / desasignación más simple, más tonto posible, sin embargo, gcc emite este conjunto incluso bajo O3

sub rsp, 8
mov edi, 4
call operator new(unsigned long)
mov esi, 4
add rsp, 8
mov rdi, rax
jmp operator delete(void*, unsigned long)