Acerca de [[trivial_abi]] en Clang

¡Finalmente, escribí una publicación sobre [[trivial_abi]]!

Esta es una nueva característica patentada en el tronco de Clang, nueva a partir de febrero de 2018. Esta es una extensión del proveedor del lenguaje C ++, no es C ++ estándar, no es compatible con el tronco GCC, y no hay propuestas activas de WG21 para incluirlo en el estándar C ++, que yo sepa.



No participé en la implementación de esta función. Solo miré los parches en la lista de correo de cfe-commits y me aplaudí en silencio. Pero esta es una característica tan genial que creo que todos deberían saberlo.

Entonces, lo primero con lo que comenzaremos: este no es un atributo estándar, y el tronco de Clang no admite la ortografía estándar del atributo [[trivial_abi]] para él. En cambio, debe escribirlo en el estilo antiguo, como se muestra a continuación:

__attribute__((trivial_abi)) __attribute__((__trivial_abi__)) [[clang::trivial_abi]] 

Y, dado que este es un atributo, el compilador es muy exigente con respecto a dónde lo pega y silenciosamente agresivo si lo pega en el lugar equivocado (ya que los atributos no reconocidos simplemente se ignoran sin mensajes). Esto no es un error, esta es una característica. La sintaxis correcta es esta:

 #define TRIVIAL_ABI __attribute__((trivial_abi)) class TRIVIAL_ABI Widget { // ... }; 

¿Qué problema resuelve esto?

¿Recuerdas mi publicación el 17/04/2018 donde mostré dos versiones de la clase?

Nota perev: Dado que la publicación del 17/04/2018 tiene un pequeño volumen, no lo publiqué por separado, sino que lo inserté aquí debajo del spoiler.

 struct Foo { int value; ~Foo() = default; // trivial }; struct Bar { int value; ~Bar() {} // deliberately non-trivial }; 

En esa publicación, se proporciona el código en el que el compilador generó código para Foo peor que para Bar. Vale la pena discutir por qué esto fue inesperado. Los programadores intuitivamente esperan que el código "trivial" sea mejor que el código "no trivial". Este es el caso en la mayoría de las situaciones. En particular, este es el caso cuando realizamos una llamada a una función o la devolvemos:

 template<class T> T incr(T obj) { obj.value += 1; return obj; } 

incr compila el siguiente código:

 leal 1(%rdi), %eax retq 

(leal es el comando x86 que significa "agregar"). Vemos que nuestro obj de 4 bytes se pasa a incr en el registro% edi, y agregamos 1 a su valor y lo devolvemos a% eax. Cuatro bytes en la entrada, cuatro bytes en la salida, fácil y simple.

Ahora veamos incr (el caso con un destructor no trivial).

 movl (%rsi), %eax addl $1, %eax movl %eax, (%rsi) movl %eax, (%rdi) movq %rdi, %rax retq 

Aquí, obj no se pasa en el registro, a pesar del hecho de que aquí los mismos 4 bytes con la misma semántica. Aquí se pasa obj y se devuelve a la dirección. Aquí la persona que llama reserva un espacio para el valor de retorno y nos pasa un puntero a este espacio en rdi, y la persona que llama nos da un puntero para el valor de retorno obj en el siguiente registro de argumentos% rsi. Extraemos el valor de (% rsi), agregamos 1, lo guardamos de nuevo en (% rsi) para actualizar el valor de obj, y luego (trivialmente) copiamos 4 bytes de obj en la ranura para el valor de retorno señalado por% rdi. Finalmente, copiamos el puntero original pasado por la persona que llama de% rdi a% rax, ya que el documento x86-64 ABI (p. 22) nos dice que hagamos esto.

La razón por la que Bar es tan diferente de Foo es porque Bar tiene un destructor no trivial, y el x86-64 ABI (p. 19) establece específicamente:

Si un objeto C ++ tiene un constructor de copia no trivial o un destructor no trivial, se pasa a través de un enlace invisible (el objeto se reemplaza con un puntero [...] en la lista de parámetros)

Un documento posterior de Itanium C ++ ABI define lo siguiente:

Si el tipo de parámetro no es trivial para el propósito de la llamada, la persona que llama debe asignar un lugar temporal y pasar un enlace a este lugar temporal:
[...]
Un tipo se considera no trivial para el propósito de la llamada si:

Tiene un constructor de copia no trivial, un constructor móvil, un destructor, o todos sus constructores móviles y de copia se eliminan.

Esto explica todo: Bar tiene una generación de código más pobre porque se pasa a través de un enlace invisible. Se transmite a través de un enlace invisible ya que se ha producido una combinación desafortunada de dos circunstancias independientes:

• El documento ABI dice que los objetos con destructor no trivial se pasan a través de enlaces invisibles
• Bar tiene un destructor no trivial.

Este es un silogismo clásico: el primer punto es la premisa principal, el segundo es privado. Como resultado, Bar se transmite a través de un enlace invisible.

Que alguien nos dé un silogismo:

• Todas las personas son mortales
• Sócrates es un hombre.
• En consecuencia, Sócrates es mortal.

Si queremos refutar la conclusión "Sócrates es mortal", debemos refutar una de las premisas: refutar lo principal (quizás algunas personas no son mortales) o refutar lo privado (quizás Sócrates no es una persona).

Para que Bar se apruebe en un registro (como Foo), debemos refutar una de las dos premisas. La ruta estándar de C ++ es darle a Bar un destructor trivial, destruyendo la premisa privada. Pero hay otra manera!

Cómo [[trivial_abi]] resuelve el problema

El nuevo atributo Clang destruye la premisa principal. Clang extiende el documento ABI de la siguiente manera:

Si el tipo de parámetro no es trivial para el propósito de la llamada, la persona que llama debe asignar un lugar temporal y pasar un enlace a este lugar temporal:
[...]
Un tipo se considera no trivial a los efectos de la llamada si está marcado como [[trivial_abi]] y:
Tiene un constructor de copia no trivial, un constructor móvil, un destructor, o todos sus constructores móviles y de copia se eliminan.

Incluso si una clase con un constructor o destructor en movimiento no trivial puede considerarse trivial para el propósito de la llamada, si está marcada como [[trivial_abi]].

Así que ahora, usando Clang, podemos escribir así:

 #define TRIVIAL_ABI __attribute__((trivial_abi)) struct TRIVIAL_ABI Baz { int value; ~Baz() {} // deliberately non-trivial }; 

compile incr <Baz> y obtenga el mismo código que incr <Foo>!

Advertencia # 1: [[trivial_abi]] a veces no hace nada

Espero que podamos hacer envoltorios "triviales para llamadas" sobre tipos de biblioteca estándar, como este:

 template<class T, class D> struct TRIVIAL_ABI trivial_unique_ptr : std::unique_ptr<T, D> { using std::unique_ptr<T, D>::unique_ptr; }; 

Por desgracia, esto no funciona. Si su clase tiene alguna clase base o campos no estáticos que son "no triviales para el propósito de la llamada", entonces la extensión Clang en la forma en que está escrita ahora hace que su clase sea "irreversiblemente no trivial", y el atributo no tendrá efecto. (No se emiten mensajes de diagnóstico. Esto significa que puede usar [[trivial_abi]] en la plantilla de clase como un atributo opcional, y la clase será "condicionalmente trivial", lo que a veces es útil. La desventaja, por supuesto, es que puede marque la clase como trivial y luego descubra que el compilador la arregló en silencio).

El atributo se ignora sin mensajes si su clase tiene una clase base virtual o funciones virtuales. En estos casos, es posible que no quepa en los registros, y no sé qué quiere obtener al pasarlo por valor, pero probablemente lo sepa.

Entonces, que yo sepa, la única forma de usar TRIVIAL_ABI para "tipos utilitarios estándar" como opcional <T>, unique_ptr <T> y shared_ptr <T> es

• impleméntelos usted mismo desde cero y aplique el atributo, o
• irrumpir en su copia local de libc ++ e insertar el atributo allí con las manos

(en el mundo de código abierto, ambos métodos son esencialmente iguales)

Advertencia # 2: responsabilidad del destructor

En el ejemplo con Foo / Bar, la clase tiene un destructor vacío. Deje que nuestra clase tenga un destructor no trivial.

 struct Up1 { int value; Up1(Up1&& u) : value(u.value) { u.value = 0; } ~Up1() { puts("destroyed"); } }; 

Esto debería serle familiar, esto es unique_ptr <int>, simplificado al límite, con el mensaje impreso cuando se elimina.

Sin TRIVIAL_ABI, incr <Up1> solo se parece a incr <Bar>:

 movl (%rsi), %eax addl $1, %eax movl %eax, (%rdi) movl $0, (%rsi) movq %rdi, %rax retq 

¡Con TRIVIAL_ABI, incr parece más grande y aterrador !

 pushq %rbx leal 1(%rdi), %ebx movl $.L.str, %edi callq puts movl %ebx, %eax popq %rbx retq 

En la convención de llamada tradicional, los tipos con un destructor no trivial siempre pasan por un enlace invisible, lo que significa que el lado receptor (incr en este caso) siempre acepta un puntero a un objeto de parámetro sin poseer este objeto. El objeto es propiedad de la persona que llama. ¡Esto hace que el trabajo de elisión funcione!

Cuando se pasa un tipo con [[trivial_abi]] en los registros, esencialmente hacemos una copia del objeto de parámetro.

Como x86-64 solo tiene un registro para devolver (aplausos), la función llamada no tiene forma de devolver el objeto al final. ¡La función llamada debería tomar posesión del objeto que le pasamos! Esto significa que la función llamada debe llamar al destructor del objeto de parámetro cuando finalice.

En nuestro ejemplo anterior, Foo / Bar / Baz, se llama al destructor, pero estaba vacío y no lo notamos. Ahora en incr <Up2> vemos código adicional generado por el destructor al lado de la función llamada.

Se puede suponer que este código adicional se puede generar en algunos casos de usuario. Pero, por el contrario, ¡la llamada del destructor no aparece en ningún lado! Se llama en incr porque no se llama en la función de llamada. Y en general, el precio y los beneficios serán equilibrados.

Advertencia # 3: Orden del Destructor

El destructor para un parámetro con un ABI trivial será llamado por la función llamada, y no por la llamada (advertencia No. 2). Richard Smith señala que esto significa que no se lo llamará en el orden en que se encuentran los destructores de los otros parámetros.

 struct TRIVIAL_ABI alpha { alpha() { puts("alpha constructed"); } ~alpha() { puts("alpha destroyed"); } }; struct beta { beta() { puts("beta constructed"); } ~beta() { puts("beta destroyed"); } }; void foo(alpha, beta) {} int main() { foo(alpha{}, beta{}); } 

Este código imprime:

 alpha constructed beta constructed alpha destroyed beta destroyed 

cuando TRIVIAL_ABI se define como [[clang :: trivial_abi]], imprime:

 alpha constructed beta constructed beta destroyed alpha destroyed 

Relación con un objeto "trivialmente reubicable" / "mover-reubicar"

Sin relación ... ¿eh?

Como puede ver, no hay requisitos para que la clase [[trivial_abi]] tenga una semántica específica para el constructor en movimiento, el destructor o el constructor predeterminado. Cualquier clase particular probablemente será trivialmente reubicable, simplemente porque la mayoría de las clases son trivialmente reubicables.

Simplemente podemos hacer la clase offset_ptr para que no sea reubicable trivialmente:

 template<class T> class TRIVIAL_ABI offset_ptr { intptr_t value_; public: offset_ptr(T *p) : value_((const char*)p - (const char*)this) {} offset_ptr(const offset_ptr& rhs) : value_((const char*)rhs.get() - (const char*)this) {} T *get() const { return (T *)((const char *)this + value_); } offset_ptr& operator=(const offset_ptr& rhs) { value_ = ((const char*)rhs.get() - (const char*)this); return *this; } offset_ptr& operator+=(int diff) { value_ += (diff * sizeof (T)); return *this; } }; int main() { offset_ptr<int> top = &a[4]; top = incr(top); assert(top.get() == &a[5]); } 

Aquí está el código completo.
Cuando se define TRIVIAL_ABI, la troncal de Clang pasa esta prueba en -O0 y -O1, pero en -O2 (es decir, tan pronto como intenta en línea las llamadas a trivial_offset_ptr :: operator + = y al constructor de la copia), se bloquea en la afirmación.

Entonces una advertencia más. Si su tipo hace algo tan loco con este puntero, probablemente no quiera pasarlo en los registros.

Bug 37319 , de hecho, una solicitud de documentación. En este caso, resulta que no hay forma de hacer que el código funcione de la manera que el programador quiere. Decimos que el valor de value_ debe depender del valor de este puntero, pero en el límite entre las funciones de llamada y llamadas, ¡el objeto está en registros y el puntero no existe! Por lo tanto, la función de llamada lo escribe en la memoria y pasa el puntero de este nuevamente, y ¿cómo debería la función llamada calcular el valor correcto para escribirlo en value_? Quizás sea mejor preguntar cómo funciona incluso en -O0. Este código no debería funcionar en absoluto.

Por lo tanto, si desea utilizar [[trivial_abi]], debe evitar las funciones de los miembros (no solo especiales, sino cualquiera en general) que dependen en gran medida de la propia dirección del objeto (con un significado indefinido de la palabra "esencial").

Intuitivamente, cuando una clase se marca como [[trivial_abi]], cada vez que espera copiar, puede obtener copia más memcpy. Y de manera similar, cuando esperas un movimiento, puedes obtener el movimiento más memcpy.

Cuando un tipo es "trivialmente reubicable" (como lo definí en C ++ ahora ), cada vez que espere copiar y destruir, puede obtener memcpy. Y de manera similar, cuando esperas desplazamiento y destrucción, puedes obtener memcpy. De hecho, las llamadas a funciones especiales se pierden si hablamos de "reubicación trivial", pero cuando la clase tiene el atributo [[trivial_abi]] de Clang, las llamadas no se pierden. Simplemente obtienes (por así decirlo) memcpy además de las llamadas que esperabas. Esta (especie de) memoria es el precio que paga por una convención de registro de llamadas más rápida.

Enlaces para lecturas adicionales:

El hilo cfe-dev de Akira Hatanaka de noviembre de 2017
Documentación oficial de Clang
La unidad prueba para trivial_abi
Error 37319: trivial_offset_ptr no puede funcionar