==========================================
 Julian, Laure, Matthieu, 23 mai. Nautibus
==========================================


Rappel des deadlines :
- 30 mai : Rapport
- 3 juin : Dépot du poster
- 6 juin : Présentation du poster
- 11 juin : Vidéo



== Rapport ==

- Est-ce le cas avec clang : on s'attendrait à une phrase du genre "comme le
cas dans Clang" et enlever le faux suspens "ça serait bien si les compilateurs
faisaient ça"

- Mettre la section 2.3.4 (Travaux précédents) à la fin du rapport pour enlever
le suspens "A fait ça mais pas nous. B fait ça mais pas nous. (...) Z fait ça
mais pas nous.". Dire que "ce problème est appelé Phase Ordering" dans l'intro
du 3.

- Les contributions sont : le rapport qui donne une vue d'ensemble, les notes
et les programmes

- Mettre en annexe les notes de llvm test suite et faire références aux notes
pour montrer que le seul apport n'est pas une modification du fichier de
génération.

- Dans la conclusion, mieux expliciter qu'il y a des améliorations techniques
possibles ainsi qu'il y a des questions scientifiques également (cf section
poster)

Le rapport est globalement ok (modulo les fautes)


== Review du Poster ==

- Limiter les phrases (Option O0 à O3 : séquence prétablie de passes pour
optimiser)

- Il y a une typo "choisis" -> "choisie"

- Plutôt que de demander "Quel est le meilleur ordre possible", demander
"Comment évaluer l'effet d'un ordre ?"

- Schéma de script individuel : mettre en évidence que clang n'est pas une
entrée au même titre que le programme (en mettant par exemple en haut clang)

- Pour la section "Utilisation de la test-suite", la version actuelle peut
se résumer à "on a fait un script sed" alors que ce qu'il faudrait plus mettre
en avant pourquoi on a fait un script sed.

- Dire qu'elle contient 297 POUR mesurer les performances (pour lever un peu
l'ambiguité "il y a que 297 tests ?").

- Pour dire "LLVM c'est compliqué", éventuellement mettre quelques chiffres
(nombre de fichiers par exemple).

- Faire le même schéma pour la test-suite que pour le script individuel en
montrant "cette fois on a la test suite qui contient plein de programmes, on
veut la compiler puis la tester"

- Face au manque de place, on peut enlever le bout de script et se contenter de
dire que les recherches ont abouti à une modification automatique du script de
génération.

- Mettre en avant les avantages de la solution proposée
((+) les avantages de ma soliution c'est automatique, ça réutilise la test
suite blabla)

- Section pistes :

Travuaux futur :

o Amélioration techniques :

 - étendre à d'autres métriques
 - patcher le driver de passes de clang

o Questions de recherches
 - que sont deux passes qui commutent (en quantité ex : ça commute à 98%)
 - Comment faire un retour au dev des passes ?

(Il faut au moins poser les questions)


== Vidéo ==

Pour le moment rien n'est fait pour la vidéo (pas d'idée de comment orienter
la vidéo)


- Proposition de déroulement :

"Je suis un utilisateur j'utilise un programme.
Il a été écrit par un développeur qui a utilisé un compilateur
Celui qui écrit un compilateur il écrit des passes et il aimerait pouvoir
montrer que ses passes d'optimisations elles sont super
Hey moi j'arrive avec mon outil qui permet de mesurer à quelles points les
passes sont super"


- Inutile de parler de comment ça a été fait : se contenter d'expliciter le
problème et montrer qu'il y a des résultats sous forme de graphiques.

- Le but de la vidéo est de donner envie aux spectateurs de lire le rapport ou
d'avoir envie de regarder le git pour en savoir plus.
  Comparable à une présentation de 25 minutes : garder les éléments les plus
simples pour que l'auditoire ne s'ennuie pas / ne soient pas perdu dans
la complexité, et laisser ceux qui ont été intéressés par le sujet lire chez
eux le papier scientifique qui donne tous les détails.


Longueur approximative pour 3 minutes :
- Environ 69 lignes
- 3 slides