Laure, Julian et Sébastien (2019-04-30, 16:30-18:00)

== Version de Sebastien ==

Début de passation de sujet. Sur le plan pratique, passage en revue du dépôt où
Julian a travaillé (https://gitlab.inria.fr/mmoy/llvm-pass-analysis) avec un
aperçu de la documentation et des scripts présents.

Discussions réparties en la philosophie et la technique pour cerner le sujet.
-> Objectifs  : Améliorer les performances temporelles de programmes
                Obtenir du feedback pour les passes d'analyse
                Métaphysiquement, coupler des passes d'analyse et d'opti
-> Moyens     : Instrumentation de la compilation (clang, opt, clang)
                Driver pour opt permettant de choisir les passes à exécuter
                Analyse de la vitesse des programmes en sortie
                Plein de scripts de statistiques trop cools

L'architecture de LLVM nous impose quand même ses limites.

* L'exécution et l'ordre des passes est décidé par clang (contredit l'un des
  points précédents, à revoir...)
* Au profit de la modularité, les passes d'analyse sont contraintes à n'exposer
  en résultat qu'une interface de décision, pas une structure de données
* Il est possible de transmettre des données entre les passes, mais en pratique
  ça se produit peu
* Il est pas gagné d'avance d'instrumenter opt/clang/whatever pour se caler
  entre les passes et observer les changements produits.
* Les passes d'opti n'utilisent l'interface que d'un nombre limité de passes
  d'analyse et ne peuvent donc pas exploiter d'informations supplémentaires.

Il est déjà difficile rien que décider quelles passes sont produites par
[opt -O3] puisque les tests de Julian ne donnent pas la même vitesse en sortie
lorsque les passes supposément appliquées par [opt -O3] sont exécutées.

Pour pousser un peu plus loin, il semble (pour l'instant) intéressant de se
poser les questions suivantes :

* Comment tester si une modification a eu un effet sur le programme final ?
  -> Niveau 1 : Comparer la vitesse des deux versions
                Tester si le même code intermédiaire est obtenu en sortie
  -> Niveau 2 : Effectuer des diffs souples (notamment au niveau syntaxique)
  -> Niveau 3 : Instrumenter le code pour détecter des prises de décision ?

* Quelles mesures d'équivalence entre deux programmes ?
  Deux passes qui commutent dans le cas général risque d'être rare, mais en se
  restreignant aux programmes réels et modulo une certaine équivalence, on peut
  imaginer chercher des relations plus grosses.


== Version de Julian ==


Passation :

- Travail réalisé jusque là : plus un travail technique / analyse de clang / des
possibilités. Travail du stage de Sebastien : plus un travail de recherche.

- L'abondance de notes et les petits scripts ont été fortement appréciés.


LLVM :

- Les phases analyses ajoutent des méta données / proposent une interface et donc
ne modifient en aucun cas les fichier .ll que l'on peut générer. Elles peuvent
aussi construire une structure de données interne.

- Peu de différence de temps entre o3 licm gvn et o3 gvn licm, solution : on peut
mesurer plutot les différences sur l'IR (ie quel ordre modifie le plus le code).

Meta :

- La vie d'un chercheur, c'est faire des choses qui seront rapidement obsolètes
pour montrer quelques résultats intéressants, qu'on peut le faire et pourquoi.
- LLVM c'est bien parce que c'est modulaire. C'est pas bien parce que c'est
modulaire (les passes d'analyses proposent une interface aux passes
d'optimisation pour répondre soit oui, soit peut-être -> perte possible
d'information)