Laure, Matthieu, Sébastien Mo et Sébastien Mi (2019-05-24, 16:30-17:15 Paris)

En termes d'activité jusqu'à présent, Sébastien a travaillé sur deux points :

1. Prise en main des scripts de Julian et reproduction manuelle de [opt -O3].

   L'idée est de ne pas utiliser la sortie binaire directe de clang comme point
   de repère, mais de l'utiliser comme front-end et faire le reste du pipeline
   à la main. On peut alors reproduire sans difficulté le résultat de [opt -O3]
   avec une liste d'optimisations extraite d'une exécution quelconque.

   Matthieu fait remarquer qu'il faut vérifier que le pipeline décomposé a bien
   les mêmes perfs que clang tout entier.

2. Analyse d'informations sur les passes et construction d'une base de données.

   À partir d'une analyse de code source (grep, cut et parsing), Sébastien a
   sorti les métadonnées et relations de dépendances/préservations entre les
   ~500 passes définies dans la bibliothèque de LLVM.

   On peut ensuite importer ces données dans une base Neo4j et commencer à se
   poser des questions intéressantes, notamment mettre en relation les
   dépendances/échelles avec la commutativité, ou mesurer l'impact a priori
   d'une passe d'analyse sur le reste du pipeline.

# Des pistes de recherche à explorer

Ces deux aspects relèvent encore de l'ingénierie et il reste à se poser les
bonnes questions de recherche pour orienter le sujet. Plusieurs perspectives
d'exploration se présentent :

-> Étudier la commutativité des passes, pour chercher des paires qui commutent
   ou qui peuvent être interverties pour améliorer le niveau d''optimisation.
-> Creuser la déclaration des dépendances et la possibilité d'avoir des
   dépendances sur- ou sous-contraintes dans la chaîne.
-> Définir des notions souples de commutation ou conflit sur les passes, qui
   se ramènent souvent à une notion d'équivalence de programmes.

Les pistes se recroisent ; on pourrait par exemple découvrir une dépendance
"faible" entre A et B, au sens où exécuter A améliore ou détériore l'effet de
B sur le programme, et en déduire une interversion ou l'insertion d'une
nouvelle passe, qui augmente les performances du programme optimisé.

Les tests peuvent être réalisés soit en isolation, dans une optimisation avec
une poignée de passes que l'on veut étudier, soit dans le contexte, avec tout
le pipeline d'optimisation usuel de clang. On retiendra que le premier type est
approprié pour détecter les modifications qui ont un impact, et que le second
est nécessaire pour valider cet impact en conditions réelles.

# Un bug à corriger sur l'associativité de opt

Concernant la commutativité, Sébastien et Sébastien suggèrent que la présence
de passes d'analyse ne devrait pas influencer les résultats car elles ne
modifient pas le programme (elles produisent seulement des informations "pures"
sur l'IR) et opt les ordonnance de façon à résoudre toutes les dépendances.

En pratique ça marche la plupart du temps, mais avant de le supposer il faut
s'assurer que ce n'est invalidé par un exemple qui ne fonctionne pas encore,
l'associativité de opt. Pour l'instant [opt -a -b] et [opt -a | opt -b] ne
produisent pas le même résultat, ce qui est problématique pour avoir un modèle
théorique un minimum solide.