2010-12-04 13 views
5

¿Hay alguna herramienta donde haya derramado mi código c?Herramientas para mostrar los derrames en un código c

Me refiero a ver qué bloque de código potencialmente hace que un registro se mueva a la memoria.

EDIT: ¿qué es un derrame:

En el proceso de compilar el código en algún momento tendrá que hacer asignación de registros. El compilador hará un gráfico de interferencia ("variables" son nodos y están conectados si están vivos al mismo tiempo). A partir de este punto hay un proceso lineal que hará el coloreado gráfico: para cada variable asigne un registro que no interfiera con otras variables ... Si no tiene suficiente registro para colorear el gráfico, el algoritmo fallará y una variable (registro) se derramará (se moverá a la memoria).

Desde el punto de vista de la ingeniería de software, esto significa que siempre debe minimizar una variable en vivo para que pueda minimizar la posibilidad de un derrame.

Cuando desee optimizar el código, debe buscar ese tipo de cosas ya que un derrame le dará un tiempo extra para leer/escribir en la memoria. Estaba buscando una herramienta o un indicador del compilador que pudiera decirme dónde está el derrame para que pueda optimizarlo.

+4

¿Qué es un derrame? –

+1

Echa un vistazo a mi edición :-) –

+0

gracias por la explicación! –

Respuesta

4

No conozco ninguna herramienta de este tipo.

Como las decisiones sobre los derrames varían de compilador a compilador, y versión del compilador e incluso por configuración dentro de una versión determinada de un compilador determinado, cualquier herramienta debería estar estrechamente acoplada a un compilador y probablemente solo admitiría uno .

Por otro lado, siempre puede mirar el ensamblaje generado usted mismo y ver si una variable dada se derrama o no.

+0

Bueno, una herramienta que podría funcionar con el compilador y su salida de ensamblaje para automatizar una buena parte del proceso sería muy agradable. –

+0

@R. Si entendiste mi punto. Podría buscar el código ensamblador, pero tendré que analizar para encontrar la variable/bloque de código que causó el derrame. Creo que el derrame es causado por dos cosas, vivo de variables y la cantidad de registro. Podría tener una función larga con variables con rango de vida larga que podría ser refactor para tener menos derrame. –

+0

@Guillaume Massé: siempre puede refactorizar sus funciones para reducir las posibilidades de derrames ... pero es probable que el optimizador del compilador haga un buen trabajo de todos modos (y si no lo hace, obtenga un mejor compilador). –

0

Generalmente, desmonte o compile para ensamblar en lugar de un objeto.

Para compiladores específicos como gcc y llvm (donde tiene la fuente y puede volver a compilar fácilmente el compilador), modifique el compilador para imprimir algún tipo de resultado para indicar cuántas veces tuvo que derramarse, como lo llama a la memoria Tal vez cuando encuentre la rutina de asignación de registros, puede encontrar que el compilador ya tiene dicha salida. Personalmente desarmo o compilo para ensamblador.

Es posible una herramienta de análisis de ensamblador genérico, pero ¿vale la pena el esfuerzo? Desearía saber dónde están los límites de función/optimización. Querrá distinguir las variables volátiles, o los registros de hardware donde la escritura a RAM fue intencional. Solo podría buscar escrituras basadas en pila solamente. O busque los casos donde hay una escritura en la pila que no es un empuje, donde el registro se destruye en la próxima instrucción. En realidad, sería bastante fácil buscar escrituras en una dirección relativa de puntero de pila, con la siguiente instrucción destruyendo el registro, con esa dirección relativa basada en pila siendo leída en una ruta de ejecución relativamente cercana donde el marco de pila no ha sido limpiado ese camino de ejecución. ¿Conozco una herramienta así? Nop.

Cuestiones relacionadas