G´en´eration de code pour l’architecture cible

Dans les paragraphes pr´ec´edents, nous nous sommes int´eress´es `a la notion de motifs de calcul dans un PRDG. Les ordonnancements modulaires sont utilis´es pour formuler un probl`eme conjoint d’ordonnancement affine et de couverture du PRDG, dont le r´esultat est la s´election d’un ensemble de macroblocs ex´ecut´es sur l’extension mat´erielle d’un processeur extensible. Nous pr´esentons maintenant la mani`ere d’exploiter le r´esultat de cette couverture sur l’architecture cible.

6.3. Formulation du probl`eme 135 6.3.3.1 Exploitation de l’extension mat´erielle

L’architecture cible est un processeur extensible (e.g., NiosII) fortement coupl´e `a une extension mat´erielle. Tout comme l’approche pr´esent´ee dans le chapitre3, cette extension mat´erielle b´en´eficie d’un acc`es direct `a la file de registres du processeur et dispose d’un nombre limit´e de bus d’entr´ee et de sortie pour communiquer avec le processeur. La diff´erence porte sur le fait que les motifs s´electionn´es dans le graphe correspondent cette fois `a des macroblocs pouvant contenir plusieurs instructions sp´ecialis´ees (l’instruction sp´ecialis´ee k est not´ee ISk).

La figure6.4pr´esente le fonctionnement g´en´eral de l’architecture cible. Par souci de simplicit´e, on consid`ere qu’`a chaque macrobloc s´electionn´e correspond un composant mat´eriel d´edi´e sur l’extension. Il existe clairement des possibilit´es de r´eutilisation du mat´eriel de l’extension, que ce soit au niveau intra ou inter macroblocs. Ainsi, l’information sur les domaines de d´efinition des instructions sp´ecia- lis´ees pourrait ˆetre avantageusement exploit´ee pour fusionner des op´erateurs (i.e., l’addition de l’IS2 et de l’IS3) dont l’ex´ecution est exclusive sur une mˆeme ressource mat´erielle. Toutefois, la synth`ese et l’optimisation du mat´eriel de l’extension sont des probl`emes complexes qui n’ont pas ´et´e abord´es dans le cadre de cette th`ese. De plus, nous ne proposons pas d’approche permettant de traiter l’int´e- gralit´e du probl`eme de vectorisation. En effet, nous nous contentons de s´electionner des instructions qui sont potentiellement vectorisables. Les probl´ematiques de synth`ese d’architecture et de gestion de la m´emoire que pose la vectorisation ne sont, pour l’instant, pas trait´ees et constituent autant de perspectives int´eressantes.

Chaque composant d’un macrobloc dispose d’un contrˆoleur charg´e de configurer le chemin de don- n´ees en fonction du code de l’op´eration (opcode) transmis par le processeur. En effet, il est souvent n´ecessaire de d´ecomposer en plusieurs ´etapes le comportement de chaque instruction sp´ecialis´ee d’un macrobloc. Chaque ´etape correspond alors `a une instruction sp´ecialis´ee primitive qui est identifi´ee de mani`ere unique par un opcode. Cette d´ecomposition est une cons´equence des contraintes architec- turales qui limitent, par exemple, le nombre d’op´erandes d’une instruction ex´ecut´ee sur l’extension (cf. paragraphe3.2.2.4, page51). Ainsi, le premier macrobloc du sch´ema contient l’unique instruction sp´ecialis´ee (IS1) qui a ´et´e s´electionn´ee dans le calcul de la somme de quatre matrices (cf. figure6.5).

Le calcul `a effectuer comporte quatre op´erandes et si l’extension ne dispose que de deux bus d’entr´ee (cas du NiosII), il est alors n´ecessaire de d´ecomposer le motif en deux instructions sp´ecialis´ees primi- tives. La premi`ere transmet deux op´erandes `a m´emoriser dans les registres de l’extension. La seconde instruction sp´ecialis´ee primitive transmet les deux op´erandes restants, lance l’ex´ecution du calcul et transmet le r´esultat au processeur.

Un macrobloc qui contient plusieurs instructions sp´ecialis´ees utilise une m´emoire pour temporiser les donn´ees qui sont produites par une instruction sp´ecialis´ee et seront utilis´ees, lors d’une it´era- tion ult´erieure, par une instruction sp´ecialis´ee du mˆeme macrobloc. C’est le cas, par exemple, du deuxi`eme macrobloc du sch´ema qui contient un MAC4_(IS

2) et une op´eration d’addition (IS3) ´egale-

ment d´eport´ee sur l’extension. Une m´emoire est donc ajout´ee au composant mat´eriel du macrobloc. Un g´en´erateur d’adresse est charg´e de calculer les positions des diff´erentes lectures et ´ecritures dans cette m´emoire en fonction de l’opcode et de l’it´eration courante. La mise en œuvre de ce g´en´erateur d’adresse d´epend du mod`ele de m´emorisation envisag´e. Si l’on peut utiliser un buffer circulaire, la mise en œuvre est triviale : une simple machine `a ´etat effectue l’adressage modulo la taille du buffer.

136 Chapitre 6. Espace conjoint de sp´ecialisation et d’optimisation de code 1 for(i=0;i<N;i++){ //Parallel dimension

2 for(j=0;j<N;j++){ //Parallel dimension

3 custom_add3(A[i][j],B[i][j],C[i][j],D[i][j],&G[i][j]);

4 }

5 }

1 void custom_add3(int v1, int v2, int v3, int v4, int *result){ 2 asm volatile("

3 custom 1, %0, %1; /*Load two operands*/

4 custom 2, %2, %3, %4;"/*Load remaining operands, launch execution and store the result*/

5 :"r"(v1) 6 :"r"(v2) 7 :"r"(v3) 8 :"r"(v4) 9 :"=r"(result) 10 ); 11 }

Figure 6.6 – Utilisation s´equentielle de la nouvelle instruction sp´ecialis´ee sur un NiosII . Les ins- tructions en assembleur correspondent `a l’envoi des op´erandes et au lancement de l’ex´ecution sur l’extension.

6.3.3.2 G´en´eration de code

Le moyen le plus simple d’exploiter les r´esultats de la couverture et de l’ordonnancement du PRDG est de g´en´erer une nouvelle version du code source de l’application qui contient les appels explicites des instructions sp´ecialis´ees s´electionn´ees. Le compilateur natif du processeur sera ensuite charg´e de produire le code binaire.

Cependant, `a la diff´erence d’un flot standard d’extension de jeu d’instructions, la repr´esentation in- term´ediaire d´etermine ´egalement la structure du programme (domaines d’it´erations des nœuds). L’or- donnancement affine du PRDG risque d’avoir modifi´e cette structure et un outil tel que CLOOG [18] est indispensable pour g´en´erer un parcours (sous forme de nids de boucles et de conditions affines) de l’ensemble des points des domaines ordonnanc´es. Lors de cette ´etape, les instructions standard et sp´ecialis´ees sont r´eparties dans diff´erentes boucles. Celles-ci font notamment apparaˆıtre les fusions ou fissions issues des ´eventuelles dimensions scalaires des ordonnancements.

La syntaxe des appels aux instructions sp´ecialis´ees d´epend du processeur dont le jeu d’instruction est ´etendu. Dans le cas du NiosII, il est possible d’utiliser des Macros ou encore des instructions en assembleur pour chaque instruction sp´ecialis´ee primitive. La figure6.6 pr´esente un exemple de code g´en´er´e et qui utilise des instructions assembleurs. Le PRDG couvert et ordonnanc´e dans cet exemple est celui de la somme de quatre matrices (cf. figure 6.5) o`u une seule instruction sp´ecialis´ee a ´et´e s´electionn´ee. Celle-ci correspond dans le code `a la proc´edure custom_add3charg´ee d’initialiser et de

lancer l’ex´ecution sur l’extension. La zone de code sp´ecifique est d´elimit´ee par la construction asm volatile de GCC qui d´efinit une s´equence d’instructions en assembleur ne pouvant ˆetre optimis´ees

par le compilateur. Dans cette zone, les param`etres des instructions sp´ecialis´ees primitives sont des registres du processeur, mais leur allocation est laiss´ee au soin du compilateur et ce sont des symboles qui sont explicitement associ´es aux param`etres des instructionscustom.