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.

  - Propositions 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 TRAC pour avoir un WIKI (LIP6 ?)
    URL:    https://www-soc.lip6.fr/trac/coach/
    LOGIN:  ... (communiqué par mail)
    PASSWD: ... (communiqué par mail)

  - Un doodle pour la prochaine réunion fin Septembre, début Octobre.
    URL: http://www.doodle.com/3c8ienuspdbkinfd