Infrastructure de compilation GeCoS

3.2.1.1 Pr´esentation de l’infrastructure

GeCoS est une infrastructure de compilation, pour le langage C, dont une des particularit´es est d’ˆetre int´egr´ee `a l’environnement Eclipse4_{. Cette int´egration permet de profiter de l’importante}

extensibilit´e de l’infrastructure et offre notamment la possibilit´e de d´efinir et d’utiliser des ´editeurs textuels d´edi´es `a des langages sp´ecifiques (DSL5_{) afin de guider les diff´erentes ´etapes d’optimisation.}

Dans sa version actuelle, GeCoS est notamment utilis´e comme une infrastructure de compilation reciblable pour la synth`ese d’ASIP et/ou l’extension de processeurs programmables [121,142, 127]. GeCoS sert ´egalement de support `a des transformations source `a source (C vers C) bas´ees sur le mod`ele poly´edrique [134] ou encore comme un outil de v´erification statique de programmes OpenMP [19] int´egr´e `a l’´editeur C d’Eclipse.

Dans notre flot de conception, nous utilisons principalement deux ´el´ements de GeCoS.

1. Le front-end C, `a partir duquel nous construisons une repr´esentation interm´ediaire dans laquelle les op´erations des blocs de base et leurs d´ependances (contrˆole et donn´ees) sont repr´esent´ees sous la forme d’un graphe acyclique flot de donn´ees. Cette repr´esentation est ensuite utilis´ee pour extraire des motifs sp´ecifi´es par l’utilisateur (`a l’aide de fonctions annot´ees par la direc- tive GCS_PATTERN qui repr´esentent les motifs `a s´electionner), et qui seront utilis´es pendant le processus de couverture (tˆache 3 du flot).

2. Le back-end source `a source utilis´e lors de la phase de r´eg´en´eration d’un code C exploitant les extensions du jeu d’instructions et qui est destin´e `a ˆetre recompil´e par la chaˆıne de cross- compilation du processeur cible (NIOS2-gcc). Dans ce code C, l’appel aux extensions d´efinies par l’utilisateur se fait par l’utilisation d’instructions assembleur en-ligne.

3.2.1.2 Script de compilation

Un flot de compilation dans GeCoS est contrˆol´e par un script qui ´enonce une s´equence de passes de transformation et d’optimisation de code. Chacune de ces passes constitue un greffon de GeCoS. Le m´ecanisme de points d’extension d’Eclipse se charge ensuite de r´ealiser, `a l’ex´ecution, l’´edition

4. http://www.eclipse.org

3.2. Pr´esentation du flot de conception ASIP 47 1 ps = CDTFrontEnd("example.c"); 2 for proc in ps do 3 SSAAnalyser ( proc ) ; 4 do 5 ConstantPropagator ( proc ) ; 6 ConstantEvaluator ( proc ) ; 7 while changing ; 8 RemovePhiNode( proc ) ; 9 AlgebraicSimplifier(proc); 10 done; 11 DAGBuilder(ps); 12 AsipFlow("nios2.asipflow",ps); 13 CRegenerator(ps);

Figure 3.3 – Flot de compilation ASIP d´ecrit dans un script GeCoS.

de lien entre le cœur de l’infrastructure et les greffons qui lui sont associ´es. Le langage de script de GeCoS est non typ´e et les variables sont d´eclar´ees implicitement.

La figure 3.3montre le script GeCoS correspondant `a un flot de compilation ASIP pour le pro- cesseur extensible NiosII. La passeCDTFrontEnd(ligne 1) utilise le front-end de l’environnement de

d´eveloppement C/C++ d’Eclipse (CDT6_{) pour construire la repr´esentation interm´ediaire de GeCoS}

dont la racine est un ensemble de proc´edures. Cette repr´esentation est un CDFG7_{hi´erarchique pr´e-}

servant la structure originale du code C, les blocs de base y contiennent des instructions dans une forme arborescente.

Chaque proc´edure est ensuite transform´ee en une forme `a assignation unique (SSA8_{) qui permet}

d’appeler une passe de propagation de constante (ligne 5) et une passe d’´evaluation de constante (ligne 6) tant que celles-ci provoquent un changement dans la repr´esentation interm´ediaire de la proc´edure courante.

Une fois ces optimisations effectu´ees, la forme SSA n’est plus n´ecessaire ; la repr´esentation inter- m´ediaire est transform´ee en une forme standard (ligne 8) et une passe de simplification alg´ebrique (ligne 9) ´elimine les op´erations neutres (e.g., multiplication par 1, etc.).

Les blocs de base du CDFG sont ensuite transform´es (ligne 11) dans une repr´esentation interm´e- diaire analysable par nos outils d’extension de jeux d’instructions. Dans cet exemple, on se base sur un graphe acyclique (DAG9_{) pour repr´esenter chaque instruction primitive sous forme d’un nœud}

dont les pr´ed´ecesseurs constituent les op´erandes.

La passe suivante (ligne 12) correspond `a l’appel du flot d’extension de jeu d’instructions (cf. figure 3.3) sur l’ensemble des proc´edures du fichier C. Les param`etres du flot sont d´ecrits par un fichier externe dans un langage sp´ecifique.

6. C Development Tooling :http://www.eclipse.org/cdt/

7. Control Data Flow Graph 8. Single Static Assignement 9. Directed Acyclic Graph

48

Chapitre 3. S´election et ordonnancement simultan´e d’instructions pour processeurs sp´ecialis´es

3.2.1.3 Contributions logicielles dans GeCoS

Au cours de cette th`ese, l’infrastructure GeCoS nous a servi de support pour mettre en œuvre plusieurs approches d’extension de jeu d’instructions. Cette infrastructure a ´egalement beaucoup ´evolu´e en r´eponse `a nos besoins sp´ecifiques. En effet, un flot ASIP se distingue d’un compilateur pour processeur g´en´eraliste du fait qu’il explore `a la fois l’espace des transformations de code et celui des architectures mat´erielles d´edi´ees. Cette particularit´e favorise la diversit´e des repr´esentations interm´ediaires, des mod`eles d’optimisation ainsi que des interactions avec le concepteur de l’extension mat´erielle.

Dans ce contexte, nous avons contribu´e `a l’infrastructure GeCoS principalement autour des axes suivants.

• Utilisation de l’ing´enierie dirig´ee par les mod`eles (IDM). La multiplication des repr´esentations interm´ediaires et des transformations a fait apparaˆıtre un r´eel besoin d’outils transversaux aux domaines m´etiers d’un compilateur. C’est dans cette optique que cette th`ese a contribu´e `a l’int´egration des m´ethodologies de l’IDM dans l’infrastructure GeCoS. Chacune des repr´e- sentations interm´ediaires manipul´ees dans GeCoS est dor´enavant exprim´ee dans une structure commune appel´ee m´etam´etamod`ele, celle-ci permet notamment d’utiliser les multiples outils g´en´eriques issus de la communaut´e IDM. L’exp´erience acquise dans ce domaine appliqu´e `a la conception d’un compilateur optimisant fait d’ailleurs l’objet du chapitre7.

• Extensibilit´e des passes de transformation. La majorit´e des passes de transformations de code dans GeCoS s’appuie sur le patron de conception visiteur qui isole le traitement associ´e `a chaque type d’instruction. Nous avons mis en œuvre un syst`eme d’extension de ces visiteurs (bas´e sur l’infrastructure d’Eclipse) qui permet d’´etendre dynamiquement le comportement d’une transformation `a n’importe quelle repr´esentation interm´ediaire sp´ecifique non support´ee nativement par GeCoS . C’est ce syst`eme qui a notamment ´et´e utilis´e pour la reg´en´eration du code sp´ecifique au NiosII.

• Les travaux de cette th`ese ont ´egalement largement contribu´e `a l’int´egration du mod`ele poly- ´edrique (cf. chapitre 4) au sein de GeCoS : interface Java pour la manipulation de poly`edres, extraction des zones analysables par cette abstraction (SCoP10_{) et mise en œuvre d’algorithmes}

d’ordonnancement affine.