2010-01-05 2 views
3

Existe-t-il un outil permettant d'effectuer une analyse d'alias sur un programme et de savoir où gcc/g ++ doivent générer des séquences d'instructions sous-optimales en raison d'un aliasing de pointeur potentiel?Outil de détection des problèmes d'alias de pointeur en C/C++

+1

un cerveau humain? après tout, vous êtes probablement seulement intéressé par les domaines critiques de performance ..... –

+0

Qu'est-ce qu'un "sous-optimal"? Ce terme suppose qu'il existe une séquence d'instructions optimale bien connue. Je ne peux pas voir cela en général. – MSalters

+0

@Mitch Wheat: Et si quelqu'un me donne un programme de 50 000 lignes avec lequel je ne suis pas familier et dit: «Optimiser ceci»? –

Répondre

4

Je ne connais rien qui donne une couverture "100%", mais pour vectoriser le code (que l'aliasing empêche souvent), utilisez l'option -ftree-vectorizer-verbose=n, où n est un entier compris entre 1 et 6. Cela donne quelques informations une boucle n'a pas pu être vectorisée.

Par exemple, avec g ++ 4.1, le Code

//#define RSTR __restrict__ 
#define RSTR 

void addvec(float* RSTR a, float* b, int n) 
{ 
    for (int i = 0; i < n; i++) 
    a[i] = a[i] + b[i]; 
} 

résultats dans

 
$ g++ -ftree-vectorizer-verbose=1 -ftree-vectorize -O3 -c aliastest.cpp 

aliastest.cpp:6: note: vectorized 0 loops in function. 

Maintenant, passez à l'autre définition pour RSTR et vous obtenez

 
$ g++ -ftree-vectorizer-verbose=1 -ftree-vectorize -O3 -c aliastest.cpp 

aliastest.cpp:6: note: LOOP VECTORIZED. 
aliastest.cpp:6: note: vectorized 1 loops in function. 

Fait intéressant, si on passe à g ++ 4.4, il peut vectoriser le premier cas sans restriction par versioning et un contrôle d'exécution:

 
$ g++44 -ftree-vectorizer-verbose=1 -O3 -c aliastest.cpp 

aliastest.cpp:6: note: created 1 versioning for alias checks. 

aliastest.cpp:6: note: LOOP VECTORIZED. 
aliastest.cpp:4: note: vectorized 1 loops in function. 

Et ceci est fait pour les deux définitions RSTR.

+0

Je l'ai essayé sur un certain nombre d'exemples différents et cela ne m'a pas vraiment aidé. Par exemple, je l'ai essayé sur ce programme qui démontre les avantages de performance de 'restrict': http://stackoverflow.com/questions/1965487/does-the-restrict-keyword-provide-significant-anti-aliasing-benefits-in -gcc-g/1966649 # 1966649 'gcc -ftree-vectorizer-verbose = 1 -ftree-vectoriser -O3 -std = c99 -DUSE_RESTRICT restrict.c -o restreint restrict.c: 15: note: vectorisé 0 boucle fonction. restrict.c: 47: note: vectorisé 0 boucles en fonction. –

+0

@Robert Vous pouvez augmenter le niveau de verbosité si vous voulez plus d'informations. Ou -fdump-tree-alias pour voir ce que le compilateur pense de l'analyse des alias. Ou -fdump-tree-all pour tout le shebang. Pour l'exemple que vous citez, le lancement de la verbosité affiche un message "no vectype for stmt:", ce qui signifie que le matériel ne prend pas en charge un type de vecteur approprié. La solution, comme je l'ai mentionné dans une réponse à une autre de vos questions restreindre, est de spécifier -march = pentium-m et -mfpmath = sse.Cela ne contribue pas en tant que tel à cet exemple, car la boucle principale de cet exemple ne peut pas être vectorisée, restreinte ou non. – janneb

1

Dans le passé, j'ai détecté des ralentissements d'alias de cas avec l'aide d'un profileur. Certains des profileurs de console de jeu mettent en évidence les parties du code qui causent beaucoup de load-hit-store penalties - ils peuvent souvent se produire parce que le compilateur suppose que certains pointeurs sont aliasés et doivent générer les instructions de chargement supplémentaires. Une fois que vous connaissez la partie du code qui se produit, vous pouvez revenir de l'assembly à la source pour voir ce qui pourrait être considéré comme aliasé, et ajouter "restict" si nécessaire (ou d'autres astuces pour éviter les charges supplémentaires).

Je ne suis pas sûr s'il y a des profileurs librement disponibles qui vous permettront d'entrer dans ce niveau de détail, cependant. L'avantage secondaire de cette approche est que vous ne passez que votre temps à examiner les cas qui ralentissent votre code.

Questions connexes