URL: https://linuxfr.org/news/rencontre-des-developpeurs-llvm-2012 Title: Rencontre des Développeurs LLVM 2012 Authors: rewind baud123, claudex, Benoît Sibaud et Pierre Jarillon Date: 2012年11月23日T16:54:57+01:00 License: CC By-SA Tags: objective-c et firefox Score: 35 Les 7 et 8 novembre derniers a eu lieu la [Rencontre des Développeurs LLVM 2012](http://llvm.org/devmtg/2012-11/) (2012 LLVM Developers' Meeting) à San José en Californie. C'est la sixième rencontre du genre et les participants sont toujours de plus en plus nombreux. Dans son [introduction](http://llvm.org/devmtg/2012-11/Lattner-Kickoff.pdf), Chris Lattner, le père de LLVM, a fait un rapide bilan de l'année écoulée. [LLVM](http://fr.wikipedia.org/wiki/LLVM "Définition Wikipédia") (anciennement appelé Low Level Virtual Machine en français : « machine virtuelle de bas niveau ») est une infrastructure de compilateur conçue pour optimiser la compilation, l'édition de liens, l'exécution d'un programme écrit dans un langage quelconque. En plus des nouvelles fonctionnalités (notament C++11) et des nouvelles architectures prises en charge (Hexagon et MIPS64), Chris a fait état d'une communauté des développeurs LLVM et Clang très dynamique. En ce qui concerne LLVM, 78 nouveaux _committers_ (personnes qui ont du code qui a été incorporé) sont arrivés cette année pour porter le total à 167 _committers_ différents. Les chiffres sont quasiment identiques pour Clang (le frontend C/C++/Objective-C de LLVM) : 72 nouveaux _committers_ pour un total de 132. Le code source de LLVM a grossi de 131 KLoc pour un total de 1,4 MLoc tandis que le code de Clang a grossi de 260 KLoc pour un total de 1,0 MLoc. La conséquence est l'apparition de nouveaux problèmes : certains patchs ont du mal à être revus, l'infrastructure de build et de test de performance commence à montrer ses limites, la gestion des sorties de nouvelles versions se complique. Chris a donc fait un appel à la communauté pour demander de l'aide dans l'analyse des problèmes de performance, dans l'infrastructure de test, dans la documentation, etc. Il a également demandé aux contributeurs les plus impliqués de devenir «propriétaire de code» (au sens responsable dudit code). Concrètement, il s'agit de prendre en charge une sous-partie de LLVM dont le propriétaire s'engage à assurer la bonne maintenance et évolution, notamment en passant en revue les patchs concernant cette sous-partie. Immédiatement, de [nombreux volontaires](http://llvm.org/viewvc/llvm-project/llvm/trunk/CODE_OWNERS.TXT?view=markup) se sont fait connaître ou ont été proposés. La suite de la dépêche propose un résumé de quelques présentations qui ont eu lieu lors de cette rencontre. ---- [LLVM](http://llvm.org/) [Clang](http://clang.llvm.org/) [Rencontre des Développeurs LLVM 2012](http://llvm.org/devmtg/2012-11/) ---- # LLVM et Clang sur le supercalculateur le plus puissant du monde — Hal Finkel, Argonne National Laboratory Hal Finkel montre comment LLVM a été adapté sur un des plus gros super-ordinateurs du monde, le BlueGene/Q nommé [Mira](http://en.wikipedia.org/wiki/IBM_Mira) et installé au Laboratoire National Argonne, laboratoire affilié au Département US de l'Énergie. Ce super-ordinateur est classé 3^e du [Top500 de juin 2012](http://linuxfr.org/news/sortie-du-top-500-de-juin-2012). Les processeurs de ce super-ordinateur sont des [dérivés de PowerPC](http://en.wikipedia.org/wiki/PowerPC_A2) avec des capacités étendues de calcul flottant et de calcul vectoriel. Le but, en utilisant LLVM, était d'avoir un compilateur C/C++ performant et à jour. Et aussi, éventuellement, d'avoir accès à d'autres langages qui utilisent LLVM pour produire du code. Il fallait donc pour cela définir un nouveau générateur de code pour cette nouvelle architecture, en se basant sur l'architecture PowerPC déjà en place dans LLVM. Le travail n'a pas été de tout repos et a permis d'améliorer également la prise en charge de l'architecture PowerPC. Le travail va continuer, notamment autour des aspects parallélisation (OpenMP et MPI). [Résumé](http://llvm.org/devmtg/2012-11/#talk1) - [Présentation](http://llvm.org/devmtg/2012-11/Finkel-LLVMClangSupercomputer.pdf) # Le backend AArch64 : état et prévisions — Tim Northover, ARM AArch64 est le nom donné à l'architecture 64 bits des processeurs ARM. Aucun processeur réel n'est encore sorti (même s'il existe un [modèle](http://www.linaro.org/engineering/armv8/)) pour cette architecture, mais ARM travaille déjà sur un compilateur basé sur LLVM. Le but de ARM est d'avoir un compilateur pouvant générer des binaires ELF sur Linux, capable de prendre en charge les instructions assembleur, bien testé et capable de compiler du C/C++. Dans un premier temps, les optimisations sont mises de côté. Le développement du générateur de code pour AArch64 a pris neuf mois et demi. Le framework [MC Hammer](http://linuxfr.org/news/llvm-3-1-et-conference-euro-llvm-2012#toc_17) qui permet de tester de manière systématique l'ensemble des opcodes a été utilisé à nouveau pour construire une suite de tests de non-régression. Des parties plus difficiles ont été rencontrées comme les relocations, la gestion des exceptions, la gestion des informations de debug. [Résumé](http://llvm.org/devmtg/2012-11/#talk2) et [Présentation](http://llvm.org/devmtg/2012-11/Northover-AArch64.pdf) # Analyser les commentaires de documentation avec Clang — Dmitri Gribenko, HPC Center at National Technical University of Ukraine « Kiev Polytechnic Institute » Dmitri Gribenko s'est attaqué à un élément important de tout bon code source : sa documentation. Le constat de départ était que Clang ignorait superbement les commentaires et que les générateurs de document comprenaient assez mal le C++. L'idée était donc de permettre à Clang de comprendre les commentaires, pour permettre de les tenir à jour, pour permettre à d'autres outils comme les IDE ou les outils de refactoring de les comprendre et pour, peut-être, construire un meilleur outil d'extraction de documentation. Dmitri est parti de l'idée que les commentaires dans les codes sources C/C++ avaient tous le même format : le format Doxygen. Il a donc ajouté à Clang la capacité de lire et comprendre les commentaires, puis de les attacher aux bonnes déclarations. Les commentaires sont ainsi décomposés pour permettre de détecter des erreurs comme un changement de nom de paramètre non-répercuté dans la documentation, une documentation qui annonce un retour alors que la fonction n'en a pas, etc. L'outil permet aussi d'exporter les commentaires en format XML pour les traiter plus tard. Le travail ne fait que commencer mais les résultats sont déjà impressionnants et vont sans doute permettre d'améliorer la documentation du code (pour ceux qui considèrent que c'est utile). [Résumé](http://llvm.org/devmtg/2012-11/#talk3) et [Présentation](http://llvm.org/devmtg/2012-11/Gribenko_CommentParsing.pdf) # MemorySanitizer, ThreadSanitizer. Détection scalable de lecteur de mémoire non initialisée et data races avec les outils de LLVM — Kostya Serebryany, Google Kostya Serebryany présente trois outils qui sont utilisés chez Google : AddressSanitizer (ou ASan), ThreadSanitizer (ou TSan) et MemorySanitizer (ou MSan). ASan permet de détecter des erreurs tels que les usages (de mémoire) après libération et les dépassements de tampon. TSan permet de détecter une [situation de compétition](http://fr.wikipedia.org/wiki/situation de compétition "Définition Wikipédia"). MSan permet de détecter les utilisations de mémoire non-initialisée. Ces trois outils fonctionnent en instrumentant du code LLVM, appuyé par une bibliothèque externe. Comparé à des outils similaires, comme Valgrind, l'instrumentation directe permet une amélioration des performances (un ralentissement de 2 pour ASan contre 20 pour Valgrind). ASan a permit de trouver plus de 500 bugs dans Chrome en une année et demie et plus de 1000 bugs dans d'autres projets (Firefox, FreeType, LLVM, etc). TSan, quant à lui, a un ralentissement entre 2,5 et 7, mais il a permis de trouver plus de 200 bugs dans les applications serveur de Google, plus de 80 bugs dans des programmes Go, et même un bug sérieux dans OpenSSL. Pour l'instant, TSan fonctionne uniquement sur Linux 64 bits. Enfin, MSan a un ralentissement entre 3 et 6 fois, suivant qu'on veuille détecter l'origine de l'erreur ou non. MSan a permis, en deux heures, de détecter une vingtaine de bugs dans une application propriétaire de plus d'un million de lignes de code, tandis que Valgrind faisait la même chose en plus de 24 heures. [Résumé](http://llvm.org/devmtg/2012-11/#talk4) et [Présentation](http://llvm.org/devmtg/2012-11/TSan-MSan-LLVM-dev-2012.pdf) et [Poster](http://llvm.org/devmtg/2012-11/Serebryany-ASAN-TSAN-Poster.pdf) # Modules — Doug Gregor, Apple Doug Gregor présente une belle idée mais qui n'a sans doute aucune chance de voir le jour : les modules en C. Concrètement, il s'agirait d'implémenter un système de paquetage comme on peut en rencontrer dans d'autres langages (Java, Go) en remplacement des traditionnels en-têtes C. Doug analyse les faiblesses des en-têtes C : ils sont fragiles et peu performants. Là où un simple [Hello world](http://fr.wikipedia.org/wiki/Hello world "Définition Wikipédia") en C peut être écrit en 64 octets, si on prend en compte les en-têtes, ce sont 11072 octets qui sont lus. Pour C++, c'est encore pire, un Hello world de 81 octets fait en fait 1163033 octets une fois les en-têtes inclus (``). Et les en-têtes précompilés ne sont pas, selon lui, une solution. Il propose donc un système de module. Un `import` permet alors de faire appel à l'API du module importé. Par exemple, Hello world serait écrit en C : import std.stdio; int main() { printf("Hello, World!\n"); } Le module `std` comprendrait plusieurs sous-modules correspondants aux en-têtes actuels : `stdio`, `stdlib`, etc. Les modules seraient implémentés directement dans le fichier C et un outil permettrait d'extraire l'API publique, faisant ainsi disparaître les en-têtes. Pour assurer une transition douce, Gregor propose de passer par des fichiers de mapping entre les modules et les en-têtes : // /usr/include/module.map module std { module stdio { header "stdio.h" } module stdlib { header "stdlib.h" } module math { header "math.h" } } La compilation permettrait alors de mettre en cache les modules pour une réutilisation optimale, ce qui permettrait d'améliorer les temps de compilation. Les maps pourraient aussi inclure les drapeaux de compilation et de liaison. Enfin, il ne serait plus nécessaire d'inclure dans les objets toutes les bibliothèques, surtout celles à base de template (du genre `iostream`), alors qu'elles sont éliminés parce que redondante à la liaison. Ce système de module va être mis en place dans LLVM pour tester sa faisabilité. [Résumé](http://llvm.org/devmtg/2012-11/#talk6) et [Présentation](http://llvm.org/devmtg/2012-11/Gregor-Modules.pdf) # Quelle est la qualité des messages de diagnostic de Clang ? — Matt Beaumont-Gay, Google Google a fait un bilan des messages d'erreurs renvoyés par la compilation de ses applications internes avec Clang. Plus de 30000 ingénieurs-semaines ont été analysées, pour un total de presque quatre millions de diagnostics : 1472752 notes, 591 _warnings_ et 2383858 erreurs (dont 147893 provenant de `-Werror`), 34613 erreurs fatales. Parmi les erreurs les plus fréquentes, plus de 580000 sont des identifiants non-déclarés, presque 300000 sont des membres inexistants, plus de 200000 sont des types inconnus. La force de LLVM est de pouvoir proposer des corrections dans de nombreux cas. En l'occurrence, des corrections sont proposées dans 24% des cas pour les erreurs de noms de membres, dans 31% des cas pour les identifiants non-déclarés, 57% pour les types inconnus. En ce qui concerne les _warnings_, ils sont triés par les drapeaux de compilation qui les émettent. Plus de 46000 proviennent de `-Wnon-virtual-dtor`, plus de 25000 viennent de `-Wc++98-compat`, plus de 8000 de `-Wreturn-type`. L'appel à `printf` est également un grand générateur de warning. Plus de 5800 sont des erreurs de types entre celui qui est annoncé dans la chaîne de format et le type du paramètre et presque 5000 sont des paramètres qui ne sont pas des types de base du C. Parmi les erreurs de types, on trouve des couples assez connus (le premier est le type spécifié, le second le type du paramètre) : `int` vs `size_type` (plus de 500 occurrences), `char *` vs `StringPiece` (plus de 350 occurrences), `int` vs `int64` (plus de 300 occurrences). En ce qui concerne les notes (des informations ajoutées à une erreur), l'erreur qui génère le plus de notes en volume par erreur est la conversion de type [ambiguë](http://fr.wikipedia.org/wiki/wikt:ambiguë "Définition Wikipédia") (17,76 notes en moyenne, sur 41 erreurs). L'erreur la plus fréquente qui génère des notes est l'application de `sizeof` à un type incomplet (8203 erreurs). Enfin, ~~les erreurs fatales~~l'erreur fatale vient d'un fichier non trouvé. [Résumé](http://llvm.org/devmtg/2012-11/#talk8) et [Présentation](http://llvm.org/devmtg/2012-11/Beaumont-Gay-Diagnostics.pdf) # Construire un vérificateur en 24 heures — Anna Zaks, Apple et Jordan Rose, Apple Ana Zaks et Jordan Rose nous montrent comment implémenter une vérification dans l'outil [Clang Static Analyzer](http://clang-analyzer.llvm.org/), en moins de 24 heures. L'analyseur statique est chargé d'examiner tous les chemins possibles dans une application, à l'aide d'une exécution symbolique. La complexité d'une telle analyse est exponentielle, mais bornée. L'idée est, pour cet exemple, de vérifier que l'ouverture et la fermeture d'un fichier sont faites correctement : pas de double fermeture, pas de fichier laissé ouvert, pas de perte de la référence. Après avoir défini un graphe d'états possibles, les différentes transitions entre ces états sont ajoutés quand il y a un appel à `fopen` ou `fclose`. Enfin, quand une transition mène à un état d'erreur, un message est affiché. La vérification sait même traiter les deux cas où l'ouverture a échoué ou réussi. [Résumé](http://llvm.org/devmtg/2012-11/#talk13) et [Présentation](http://llvm.org/devmtg/2012-11/Zaks-Rose-Checker24Hours.pdf)

AltStyle によって変換されたページ (->オリジナル) /