Changes between Initial Version and Version 1 of reunion-2009-07-16

Timestamp:

Aug 24, 2009, 4:17:05 PM (15 years ago)

Author:

coach

Comment:

--

reunion-2009-07-16

@@ +1 @@
+{{{
+COMPTE RENDU DE LA RÉUNION DU 16 Juillet 2009
+
+-----------------------------------------------------------------
+
+La réunion avait pour objectif de définir (A) l'interfaçage entre GCC et
+les outils développés dans le cadre du projet COACH et (B) la définition
+du format d'un CDFG généré par GCC.
+Elle s'est terminée par un nombre d'actions pour la prochaine réunion (C).
+
+-----------------------------------------------------------------
+A) interfaçage entre GCC et les outils de synthèse
+
+Il existe dans la dernière version de GCC un langage nommé
+PCP qui permet d'externaliser certaines informations (les SCOP) sur les
+boucles à partir du format interne de GCC (format nommé GIMPLE).
+Il a étét conclus que ce langage ne serait pas utilisé mais que seule la
+detection des SCOP fournie par Graphite serait utilisée pour annoter directement
+GIMPLE (en interne ?) et obtenir notre CDFG au format XML (des balises seront
+utilisées pour repérer les SCOP).
+
+Le CDFG généré par GCC au format XML contiendra les SCOP
+
+
+C-Tuning et I.C.I seront utilisés pour diriger la compilation et l'ordre
+des passes d'optimisation faite dans GCC. Ceci permettra de faire la
+detection des scop en dernier dans le flot de compilation.
+
+L'utilisation de Graphite pour transformer les boucles sera possible
+(ca ne coute rien).
+
+Le Flot serait le suivant
+
+C => GCC piloté par ICI => CDFG_1 => moulinette => CDFG_2
+
+ Définition d'un unique format CDFG qui servira a décrire un modele CDFG_1
+ proche de Gimple (pour etre le plus indépendant de GCC) et un CDFG_2 qui sera
+ plus simple que CDFG_1. Il faudra donc développer un outil pour passer de
+CDFG_1 à CDFG_2.  CDFG_1 et CDFG_2 contiennent les SCOP.
+
+Exemple de transformation réalisées dans la moulinette pour passer
+de CDFG_1 vers CDFG_2  
+ - suppression des pointeurs
+ - linéarisation des tableaux
+ - Transformation des Inout des paramètres des fonctions en in out out
+   avec usne analyse de dependance de données durant la transformation de
+   CDFG_1 vers CDFG_2
+
+ Linéarisation/délinéarisation des tableaux
+
+ Suppression/transformation des pointeurs statiquement determinable
+ (passage par référence uniquement ?)
+
+-----------------------------------------------------------------
+B) Définition du format général du CDFG
+
+ FIGURE:
+   - un nom
+   - un ensemble de FIGURES
+   - un ensemble de VARIABLES
+   - un GRAPHE de BB (Basic Bloc)
+   - un ensemble de PARAMETRES
+
+ VARIABLE:
+   - un nom
+   - un type
+   les types sont:
+     * signé + bit-size
+     * non-signé + bit-size
+     * virgule fixe (signe/non-signé, bit-size, position de la virule,
+       arrondi)
+     * les pointeurs ( CDFG_1 uniquement)
+     * les strctures des types précédents et suivants.
+     * les tableaux à 1 ou plusieurs dimensions des types précédents.
+
+PARAMETRE:
+   - une variable
+   - un attribut: in, out inout
+
+ GRAPHE de BB:
+    - un ensemble de BB
+   
+ BB: 
+   - un identifiant
+   - une suite linéaire d'instruction chaque BB contient un AST proche
+     du format défini par Paul. La linéarisation des tableaux sera faite
+     à priori sur le format CDFG et non dans GCC (si c'est une passe
+     d'optimisation de GCC alors est-elle faisable en dernier via I.C.I ?
+     Dominique doit confirmer)
+   - un ensemble de couples (condition, identifiant de BB).
+   - liste(s?) des variables utilisées en entrée et sortie du BB (si gimple
+     le fournit oui sinon non . Dominique doit confirmer)
+
+Quelques précisons:
+    a) la portée des variables (SCOPE)
+       gcc a applatit le graphe => les données appartiennent à la figure
+       la plus proche (concrètement:  1 SCOPE par fonction + 1 SCOPE global).
+       Chaque fonction a ses propores variables et il existe des variables
+       globales (en dehors du main). En cas de conflits, la variable la plus
+       locale gagne (règle ANSI).
+       Les données seront préfixées par le nom de la fonction pour éviter les
+       problèmes.
+       Conservation des frontières de dominances fournies par gcc qui permettra
+       de passer en mode SSA ou alors utilisation des PHY-fonction pour faire
+       la même chose.
+    b) appel de fonction:
+       cas 1:  mise en ligne => no problem
+       cas 2:  le BB contient une instruction d'appel à une figure avec les
+               paramètres.
+               Un appel de fonction peut-il être dans un BB avec d'autres
+               instructions?
+    c) si
+       un BB peut avoir plusieurs BB successeurs. 2 comme dans Gimple
+       ou avec des arcs parallèle exprimé par des jumps ou des
+       if elsif elif .. ou switch.
+    d) boucle
+       BLOC HIERARCHIQUE qui suit le format de GIMPLE des boucles.
+       (à préciser).
+
+-----------------------------------------------------------------
+C) ACTION pour la prochaine réunion
+
+  - Dominique redigera un petit doc pour prendre en main GIMPLE ou savoir où
+  aller chercher l'information pour prendre en main ce format.
+
+  - Proposition d'une DTD ou d'un schema du CDFG (Paul & Ivan)
+  Evocation d'une utilisation d'un "double chainage" (BB => BB + flow de controle)
+
+  - Un serveur TRACK pour avoir un WIKI (LIP6 ?)
+    URL:    https://www-soc.lip6.fr/trac/coach/
+    LOGIN:  coach
+    PASSWD: co!a!ch
+
+  - Un doodle pour la prochaine réunion fin Septembre, début Octobre.
+
+
+
+}}}