c++ - sirve - seo on page se refiere a

Cómo no optimizar el alejamiento-la mecánica de una función de locura

Question

Estaba buscando una técnica de programación que asegurara que las variables utilizadas para la evaluación comparativa (sin efectos secundarios observables) no sean optimizadas por el compilador

This da algo de información, pero terminé usando la folly y la siguiente función

/**
* Call doNotOptimizeAway(var) against variables that you use for
* benchmarking but otherwise are useless. The compiler tends to do a
* good job at eliminating unused variables, and this function fools
* it into thinking var is in fact needed.
*/
#ifdef _MSC_VER
#pragma optimize("", off)
template <class T>
void doNotOptimizeAway(T&& datum) {
datum = datum;
}
#pragma optimize("", on)
#else
template <class T>
void doNotOptimizeAway(T&& datum) {
asm volatile("" : "+r" (datum));
}
#endif

Quiero usar lo anterior, pero tengo poca comprensión de su funcionamiento . Estoy más interesado en la parte no VC ++ y por qué / cómo la línea

asm volatile("" : "+r" (datum));

crea un contexto no optimizable o por qué es esto algo que uno escogería para implementar tal cosa . También sería interesante una comparación entre los 2 métodos (no sé cómo funciona pragma optimize pero parece una solución más limpia, aunque no portátil)

Answer 1

No hay una manera estándar de deshabilitar las optimizaciones, por lo que si necesita deshabilitar las optimizaciones, está limitado a lo que sea que su implementación proporcione. No tiene sentido comparar los dos enfoques a menos que encuentre un compilador que los admita.

De todos modos, en GCC,

asm volatile("" : "+r" (datum));

significa que el código de ensamblaje no verificado suministrado por el usuario está integrado en el ensamblado generado por GCC. La primera cadena literal ( "" ) contiene el código de ensamblaje para inyectar. Está vacío, por lo que en realidad no hay ningún código que se emita en absoluto.

La parte posterior a : informa a GCC sobre el efecto del código de ensamblaje. "+r" (datum) significa que GCC debe asumir que el código de ensamblaje lee y modifica la datum . A pesar de que no lo hace. El motivo es que cualquier cálculo anterior que termine de almacenar un valor en datum no puede descartarse como innecesario. Al mismo tiempo, el código de ensamblaje en sí no se puede descartar como innecesario, debido a la posible modificación del datum . volatile también marca el código de ensamblaje como un código que no debe optimizarse, como se documenta aquí :

Los optimizadores de GCC a veces descartan las declaraciones asm si determinan que no hay necesidad de las variables de salida. Además, los optimizadores pueden mover el código fuera de los bucles si creen que el código siempre devolverá el mismo resultado (es decir, ninguno de sus valores de entrada cambia entre las llamadas). El uso del calificador volatile desactiva estas optimizaciones. [...]

Parece un poco excesivo utilizar dos enfoques diferentes para evitar que se elimine el código de ensamblaje, pero supongo que es mejor estar seguro.

La restricción r significa que al código no le importa tanto el registro que GCC pone a disposición del código de ensamblaje, y se documenta aquí :

''r''
Se permite un operando de registro siempre que esté en un registro general.

El modificador + significa que el código puede leer y escribir en datum , y se documenta aquí :

''+''
Significa que este operando es leído y escrito por la instrucción. [...]