Laure, Matthieu, Sébastien Mo et Sébastien Mi (2019-05-27, 17:30-18h15 Paris) # État de l'art Quelques précisions sur la réunion du 24 Mai, qui s'était arrêtée sur des questions non résolues d'associativité. Des progrès ont été faits ; on retiendra essentiellement qu'opt est associatif à condition d'effectuer les optimisations sur de l'IR au format texte. Les subtilités incluent: * opt sans options réordonne des listes en commentaires (idempotent) ; * Le diff d'IR texte doit éliminer le nom du fichier source en commentaire. La liste LLVM a été interrogée, ce serait intéressant mais probablement pas nécessaire d'avoir le fin mot de l'histoire. Concernant la reproduction de opt -O3, Julian a été averti, dans l'idée que ça puisse préciser des interrogations dans son rapport. # Pistes de recherche visées Il y a pas mal de directions possibles et seulement deux mois de stage, il faut donc viser correctement. On a considéré trois directions principales avec différentes sous-tâches naturelles : 1. Étudier la commutation des optimisations et les gains de performance * Trouver une bonne métrique sur les programmes (diff, diff sémantique, comparaison du temps d'exécution...). Il y a pas mal d'engouement autour de cette notion, et on peut étudier des métriques relativement complexes comme des diffs structurels aux niveaux des fonctions, boucles ou blocs basiques. * Isoler des paires de passes intéressantes ; certaines vont commuter tout le temps et indiquer un certain niveau d'indépendance, d'autres vont avoir des conflits statistiquement pertinents et potentiellement des optimisations. * Étudier la commutation et les performances d'abord hors-contexte, sans avoir d'autres passes d'optimisation, puis intégrer les interversions dans le contexte d'une compilation complète au moment de valider les perfs. 2. Étudier l'impact d'une passe d'analyse sur une passe d'optimisation Typiquement pour des analyses d'aliasing. On ne peut pas retirer les passes d'analyse car le code ne le permettra probablement pas, mais on peut étudier la différence de sortie lorsque l'analyse est bateau (renvoie toujours top) ou réelle. Cela donnerait une mesure de l'impact que réalise l'analyse sur une ou plusieurs passes d'analyse plus loin dans le pipeline. 3. Étudier la pertinence des listes de dépendances Toutes les dépendances de passes sont déclarées par les développeurs des passes dans leur code. On peut tenter de trouver des situations ou les dépendances sont sur- ou sous-contraintes. Une dépendance sous-contrainte reviendrait à manquer d'une information ou d'une "forme normale" pour tirer complètement profit de la passe observée. Dans ce cas, insérer ou intervertir une passe dans le pipeline pourrait permettre de récupérer des performances. Une dépendance sur-contrainte serait typiquement une dépendance quasiment jamais exploitée. On espère notamment pouvoir les détecter les appels à travers un ltrace pour faire des statistiques. # Travail futur La direction la plus importante vis-à-vis du sujet semble être la première. On s'accorde à remarquer que la métrique de comparaison de diff n'est pas entièrement triviale, car elle indique l'égalité mais aussi la source des différences, les instructions concernées, et on peut retracer le contexte. Sébastien Mi se concentrera d'abord sur les aspects les plus simples et le développement d'une infrastructure permettant de faire marcher tous les tests. Le cahier des charges comprend notamment : * Pouvoir implémenter et tester des métriques arbitraires (future proof) * Effectuer des tests sur l'intégralité de la test suite LLVM Les métriques et questions plus élaborées seront à aborder une fois que cette partie au moins marchera. On garde enfin un oeil sur la bibliographie, avec deux axes : * Il semble y avoir des travaux sérieux déjà effectués sur les questions d'ordonnancement des passes. * De la recherche récente sur la question de comparaison de programmes.