Le projet LLVM est un ensemble de technologies modulaires et réutilisables destinées à construire des chaînes de compilation et des compilateurs. Ce projet a grandi depuis ses débuts en tant que projet de recherche à l’Université de l’Illinois pour maintenant rivaliser avec l’autre grand compilateur du monde libre. À l’aube de ses 10 ans, le projet est on ne peut plus actif, attirant aussi bien des industriels (ARM, IBM, Qualcomm, Google, Intel, etc.) que des chercheurs.

Le projet LLVM, ainsi que Clang, le compilateur C/C++/ObjectiveC officiel du projet, sont sortis dans leur version 3.3 le 17 juin 2013. LLVM apporte la prise en charge de nouvelles architectures. Clang implémente désormais la totalité du standard C++11. Ces nouveautés sont détaillées dans la seconde partie de la dépêche.

La conférence européenne LLVM 2013 qui s’est déroulée les 29 et 30 avril dernier à Paris a permis de voir certaines améliorations possibles qui seront peut-être un jour intégrées dans LLVM/Clang.

Enfin, il est important de noter que LLVM a reçu le 2012 System Software Award rejoignant ainsi Eclipse (2011), Java (2002), TCP/IP (1991) et tant d’autres.

Sommaire

• LLVM
  • Architectures
    • AArch64
    • z/Architecture
    • R600
    • x86 et ARM
    • MIPS
    • PowerPC
  • Divers
• Clang
  • Prise en charge complète de C++11
    • Prise en charge des attributs
    • Héritage de constructeur
    • Variables <code>thread_local</code>
    • C++1y
  • Divers
  • Analyseur statique
  • Un outil de migration vers C++11 : <code>cpp11-migrate</code>
• LLVM et Clang dans Debian
  • Versions journalières ( <em>nightly builds</em> ) LLVM et Clang pour Debian
  • Entrevue de Sylvestre Ledru

LLVM

Architectures

De nouvelles architectures sont désormais prises en charge par LLVM 3.3 : AArch64, z/Architecture et R600. D’autres architectures ont été améliorées : x86, ARM, MIPS et PowerPC.

AArch64

L’architecture AArch64 est la nouvelle architecture 64 bits des processeurs ARM. La particularité de cette architecture est qu’il n’existe à l’heure actuelle aucun matériel avec cette architecture. Mais sa prise en charge dans les compilateurs et dans les systèmes d’exploitation suit son cours.

En ce qui concerne LLVM, il est déjà possible de compiler du C99 ou du C++03 sur Linux si le code et les données statiques ne dépassent pas 4 Gio. Il est aussi possible de générer des informations de débogage au format DWARF.

z/Architecture

La z/Architecture est l’architecture des mainframes d’IBM zSeries. Ulrich Weigand qui travaille pour IBM a fait état de l’avancement de la prise en charge de cette architecture en précisant que LLVM était maintenant considéré comme un composant critique pour IBM. Il cite notamment l’utilisation de LLVM en tant que compilateur JIT dans le pilote Mesa/Gallium llvmpipe et dans certaines applications de base de données propriétaires. Preuve que LLVM dépasse largement le petit monde de la compilation C/C++.

R600

On a plutôt l’habitude de lire des nouvelles de l’architecture R600 dans les nouvelles du noyau au chapitre des améliorations des cartes graphiques. Et bien LLVM n’est pas en reste puisque la prise en charge de cette architecture a été ajoutée à LLVM dans le cadre du développement des pilotes libres Mesa3D. LLVM est dans ce cas utilisé en conjonction avec Gallium3D pour la prise en charge d’OpenCL et optionnellement pour la compilation des shaders OpenGL.

x86 et ARM

La nouvelle interface TargetTransformInfo permet dorénavant aux outils travaillant au niveau de la représentation intermédiaire d’avoir des informations sur le coût des instructions de manière à pouvoir faire de meilleurs choix. Cette interface a permis de définir un modèle de coût pour les architectures x86 et ARM et donc de potentiellement améliorer le code obtenu. Cette fonctionnalité est utilisée pour la vectorisation des boucles qui est maintenant activée au niveau d’optimisation -O3.

MIPS

Clang prend désormais en charge des options concernant l’ABI (32 ou 64 bits, gros-boutisme ou petit-boutisme, simple précision ou double précision). De plus, l’ensemble d’instructions DSP-ASE (Application-Specific Extension) peut maintenant être généré directement sans avoir besoin d’une fonction intrinsèque (builtin). Ces instructions servent essentiellement pour les applications multimédia.

PowerPC

La prise en charge de PowerPC a été grandement améliorée sur de nombreux points : meilleure allocation de registres, lecture et écriture 64 bits atomiques, amélioration de la génération de code pour les comparaisons et les accès mémoire non-alignés, prise en charge de setjmp/longjmp en ligne ainsi que d’instructions de PowerISA 2.04, 2.05 et 2.06.

LLVM peut maintenant lire de l’assembleur PowerPC.

Divers

La documentation de LLVM et de Clang est désormais générée à l’aide de Sphinx. Ce passage par Sphinx a permis de mettre de l’ordre dans toute la documentation et le résultat est bien plus lisible et compréhensible qu’auparavant.

Clang

Prise en charge complète de C++11

Clang prend désormais en charge l’intégralité de C++11. Les derniers éléments apparus dans Clang 3.3 sont les suivants.

Prise en charge des attributs

Clang prend en charge la syntaxe générique pour les attributs ainsi que les deux attributs [[noreturn]] (qui permet de spécifier qu’une fonction ne reviendra jamais) et [[carries_dependency]] (qui permet de prévenir le compilateur de ne pas émettre de barrière mémoire inutile).

Héritage de constructeur

Clang gère maintenant l’héritage de constructeur qui permet d’utiliser un constructeur de la classe mère sans avoir à le réimplémenter dans la classe fille. La nouvelle GCC 4.8 donne plusieurs exemples pour comprendre le principe.

Variables thread_local

Clang permet de définir des variables locales aux fils d’exécution via le mot-clef thread_local. La principale difficulté est la construction et la destruction d’objets qui sont placés dans la mémoire locale de la tâche. Il est nécessaire d’avoir une gestion au moment de l’exécution (runtime) à travers l’appel à la bibliothèque __cxa_thread_atexit qui n’est pour l’instant disponible que dans celle fournie avec G++ 4.8.

C++1y

On vient à peine de s’habituer à C++11 que la prochaine version est déjà sur les rails. Pour l’instant, C++1y apporte principalement des améliorations et des corrections par rapport à toutes les nouveautés introduites dans C++11. Ce nouveau standard devrait apparaître en 2014.

LLVM implémente déjà certaines de ces corrections qui peuvent être activées via l’option -std=c++1y.

Divers

Clang permet désormais d’utiliser des identifiants étendus pour C99 et C++, c’est-à-dire des identifiants qui utilisent certains caractères Unicode en plus des caractères ASCII traditionnels. Il est possible d’écrire ces identifiants en UTF-8 ou avec les notations \uXXXX ou \UXXXXXXXX.

Analyseur statique

L’analyseur statique de Clang a gagné quelques fonctionnalités.

L’analyse inter-procédurale a été améliorée sur de nombreux points : les constructeurs et destructeurs sont mieux traités, les faux positifs concernant le déréférencement de pointeur nul ont été diminués et l’analyse est globalement plus rapide.

Les nouvelles erreurs suivantes sont détectées :

• utilisation d’un pointeur après sa désallocation dans le cas d’un delete du C++ ;
• détection d’un allocateur et d’un désallocateur non-concordant (malloc/delete ou new/free).

Un outil de migration vers C++11 : cpp11-migrate

L’arrivée de C++11 permet d’adopter des syntaxes qui sont parfois plus concises et moins génératrices d’erreur. On pense notamment à la définition des itérateurs qui peut maintenant être évitée de deux façons, soit par le mot-clef auto qui permet d’inférer le type localement, soit via la nouvelle forme du for qui itère directement sur les éléments sans passer par un itérateur.

Seulement, de grosses bases de code utilisent la vieille syntaxe et il est impensable de devoir tout changer à la main. C’est là qu’intervient l’outil cpp11-migrate. Cet outil basé sur les bibliothèques LibTooling et LibASTMatchers permet d’automatiser ces tâches et d’appliquer des transformations au code.

À l’heure actuelle, les transformations suivantes sont prises en charge :

• le for basé sur les intervalles. Que ce soit via des itérateurs, ou en parcourant un tableau ou même un container qui implémente l’opérateur d’indexation (operator[]), la transformation se fait automatiquement ;
• l’introduction de nullptr partout où est utilisé NULL ou 0 (qui était conseillé par rapport à NULL en C++ jusque là) ;
• le remplacement du type dans une déclaration par auto. Il se fait dans les cas suivants : quand le type est un itérateur d’un container de la STL ou quand l’initialiseur est un appel à new ;
• l’ajout d’override. Quand une méthode virtuelle est ré-implémentée dans une classe fille, il est maintenant conseillé d’ajouter l’attribut override. L’outil peut s’en charger automatiquement.

Les options de cet outil permettent de calibrer le degré de modification pour être sûr de ne pas détruire tout un projet.

Cet outil a été appliqué en test sur des projets de taille assez conséquentes, LLVM et ITK, ce qui a permis de détecter de nombreux bogues, et d’améliorer son efficacité et sa robustesse. Il est prévu de l’appliquer sur LLDB, OpenCV et Poco.

LLVM et Clang dans Debian

Dès qu’on parle de LLVM/Clang et Debian, il faut bien évidemment évoquer l’énorme travail de Sylvestre Ledru. En plus de son travail d’intégration de LLVM/Clang dans Debian, vous trouverez une entrevue de ce développeur très actif.

Versions journalières ( nightly builds ) LLVM et Clang pour Debian

Des versions journalières de LLVM et Clang pour Debian et Ubuntu sont désormais construites et accessibles sur un dépôt particulier, uniquement pour les architectures i386 et amd64.

Entrevue de Sylvestre Ledru

Bonjour Sylvestre, avant toute chose, est-ce que tu peux te présenter brièvement pour ceux qui ne te connaissent pas ?

Bonjour, j’ai différentes casquettes au quotidien. Mon employeur est Scilab Enterprises. J’y fais aussi de la gestion de projets (pour des clients ou de Recherche et Développement). Je participe aussi au développement sur Scilab (logiciel libre de calcul numérique). Je travaille en parallèle pour IRILL en tant que community manager (grosso modo, je fais de la communication et je participe à l’organisation d’évènements). Par exemple, j’ai la chance d’y travailler avec Roberto Di Cosmo, Julia Lawall ou Stefano Zacchiroli. Enfin, je suis impliqué dans Debian et Ubuntu. Je maintiens plus d’une soixantaine de packages tout en étant trésorier de Debian France.

Quand as-tu été amené à t’intéresser à LLVM et pourquoi ? Est-ce que tu utilises LLVM quotidiennement et dans quel cadre ?

Initialement, je suis venu à LLVM plutôt via Clang. J’avais vu une news passer sur Linuxfr sur l’amélioration du support C et C++. Étant convaincu que compiler un logiciel avec différents compilateurs améliore la qualité du code et des applications, j’ai commencé à l’utiliser pour développer sur Scilab. Ensuite, j’ai commencé à m’y intéresser dans le cadre de Debian. Un peu à la manière dont on a réussi à proposer plusieurs noyaux (Linux, HURD et KFreeBSD), je cherche à rendre Debian agnostique en terme de compilateur. Enfin, synergie entre mes intérêts et les besoins de Scilab, dans le cadre du GTLL (Groupe Thématique Logiciel Libre) de Systematic, nous avons monté un projet intitulé Richelieu qui vise à apporter de la compilation à la volée (just-in-time) dans Scilab via LLVM/VMKit. Démarré en novembre dernier, j’en assure la coordination.

Qu’est-ce que tu trouves intéressant dans LLVM/Clang d’un point de vue technique et d’un point de vue utilisateur, en particulier en comparaison du vénérable GCC ?

D’un point de vue utilisateur, avant tout, la qualité des avertissements et erreurs. J’ai toujours un peu de mal avec les pages d’erreurs de g++ lorsque l’on traite avec les templates alors que Clang produit des messages plus clairs et plus concis. Cependant, pour être fairplay, poussé par la compétition, GCC, en particulier dans sa version 4.8, améliore aussi fortement ces points (comme par exemple le travail de Dodji Seketeli sur l’expansion des macros lors de l’affichage d’erreurs). D’ailleurs, Il ne faut pas voir gcc et clang comme des adversaires : il ne faut pas oublier qu’il avait été envisagé que LLVM soit la base d’une future version gcc.

En parallèle, LLVM/Clang proposent de nombreuses pluging/extensions très
intéressantes comme :

• scan-build, un analyseur statique de code C/C++/Objective-C pour
  trouver des bugs « complexes »
• {Address,Thread,Memory}Sanitizer qui proposent d’instrumenter du code
  binaire pour trouver des erreurs lors de l’exécution.
• libclang pour travailler sur l’arbre de syntaxe abstrait (AST) C/C++ pour écrire des plugins ou extensions (compilation source à source par exemple).

Enfin, d’un point de vue technique, c’est du code C++ bien architecturé, très bien commenté avec une grosse base de tests. Ainsi, LLVM/Clang permet à des académiques de proposer des implémentations de leurs travaux de recherche d’une manière plus simple et plus rapide qu’avec gcc.

Ça peut paraître surprenant mais la communauté LLVM est très forte et amicale. Pas mal de développeurs expérimentés (comme Duncan Sands, Rafael Espindola, etc.) encouragent et aident les débutants à contribuer. Par exemple, lorsque j’ai contribué à quelques patches pour le support de HURD et KFreeBSD dans LLVM, j’ai été surpris de recevoir un mail d’encouragement d’un développeur employé d’Apple se félicitant de voir le logiciel porté sur ces plateformes.

Tu as récemment co-organisé la conférence des développeurs LLVM Europe. Quel bilan technique et humain tires-tu de cette conférence ?

Cette conférence a été organisé par les mêmes personnes (Duncan Sands, Tobias Grosser, Arnaud De Grandmaison et moi-même) qui proposent depuis presque deux ans les Meetup LLVM. L’organisation a été facilité par la participation active de ARM et par les sponsors. En soit, la conférence fut très intéressante. Parfois un peu trop technique pour des gens pas assez dans le projet (ou pas directement intéressés par un sujet) mais dans l’ensemble, elle démontre la vigueur de la communauté (on a dû refuser beaucoup de monde à la conférence). De plus, comme la plupart des projets FLOSS, beaucoup de participants ne se voient que lors de ce genre de conférence. C’est vraiment important pour renforcer la communauté, faire progresser les projets et en lancer des nouveaux.

Les vidéos sont disponibles sur le site IRILL et Renato Golin, de Linaro, a publié un compte rendu sur le blog LLVM.

Tu es également développeur Debian et tu packages LLVM et Clang pour Debian. Peux-tu nous parler du travail que tu mènes pour pouvoir rendre Debian indépendante du compilateur ?

Mon objectif final est simple : avoir une version de Debian compilé avec Clang.

Le cheminement pour atteindre cet objectif est plus complexe. Évidement, dans un premier temps, le premier travail est d’avoir un package Clang qui fonctionne bien. Tâche pas toujours facile car Clang se base sur les headers de gcc/g++ et le runtime C++ de g++ et qu’ils ont récemment pas mal changé avec le multiarch dans Debian.

Ensuite, avec l’aide de Lucas Nussbaum, j’ai tiré parti du cloud Amazon AWS pour effectuer des reconstructions massives de l’archive Debian avec Clang. La version 3.2 a permis de valider la qualité du compilateur en terme de support du C et C++. Maintenant, l’essentiel des erreurs de compilation se trouvent dans des erreurs de programmation dans les packages upstreams. Quelques exemples :

• Fonction qui attend un argument mais qui ne retourne rien (return;).
• Des arguments invalides acceptés par gcc comme -O6 ou -O20

Cependant, il est important de préciser que ni les performances du binaire, ni la qualité de celui-ci sont testés. Pour cela, depuis quelques semaines, nous avons une infrastructure autonome de construction de packages basée sur Clang au lieu de GCC. Ce travail a été réalisé dans le cadre du Google Summer of Code 2012 par Alexander Pashaliyski, mentoré par l’hyperactif Paul Tagliamonte et moi-même. La méthode est assez bête : vu que clang accepte les mêmes arguments que gcc, on remplace le binaire gcc par clang et on lance la compilation du package de la même manière que d’habitude. Cette plateforme permet aux packageurs Debian et Ubuntu de vérifier que leurs packages compilent correctement avec Clang, et les corriger si besoin. J’espère qu’elle sera aussi utile aux développeurs de logiciel intégré dans Debian pour les encourager à corriger les problèmes soulevés par ce nouveau compilateur (et ainsi leur prouver que Clang est mature).

En parallèle, nous avons publié un dépôt Debian avec bon nombre de packages compilés avec Clang :

deb http://clang.debian.net/repository-2013-04-07/ unstable-clang main

Ce dépôt devrait permettre de tester la qualité des binaires produits.

Enfin, j’ai mis en place une instance Jenkins pour construire automatiquement des nightly builds de la toolchain LLVM pour Debian et Ubuntu. Ces dépôts sont publiés sur le site officiel de LLVM.

À plus long terme, j’aimerais pousser l’usage de /usr/bin/cc et /usr/bin/c++ au lieu de gcc et g++. Dans de nombreux packages, l’usage de gcc est hardcodé. Malheureusement, même si les retours de la communauté Debian sont dans l’ensemble positif sur cette initiative, je pense que cet objectif prendra quelques années.

Enfin, malgré tout, il restera un gros travail pour le support de certaines architectures supportées par Debian mais pas par LLVM.

Que penses-tu de l’évolution très rapide de LLVM/Clang ? Quels sont les principaux défis pour LLVM/Clang que tu vois pour le futur ?

Je trouve l’évolution de LLVM et Clang assez extraordinaire. Il y a un engouement fort à la fois autour de ce « nouveau » compilateur mais aussi autour de la plateforme qu’est LLVM en tant que tel. Les contributions se font simplement : liste des diffusions très (trop ?) actives et les permissions au SVN facilement données.

Un des exemples de réussite de la toolchain LLVM est emscripten. Projet de la fondation Mozilla, il permet de compiler des codes C/C++ en Javascript. Il utilise LLVM et Clang pour générer une représentation intermédiaire (IR) qui sera lue en Javascript.

Il y a de nombreux projets autour LLVM qui sont prometteurs comme libc++ (une nouvelle implémentation du runtime C++), lldb (un débugger tirant parti de libclang pour l’analyse de C++) ou encore lld (linker).

Quant aux défis, ça n’est un secret pour personne mais LLVM/Clang sont fortement poussés par des grosses boîtes comme Apple, Google, Intel ou Samsung. Pour leurs produits ou leur utilisation interne, ils utilisent bien souvent des révisions du dépôt Subversion. Or, en particulier d’un point de vue distributions, je pense que l’on aura besoin d’aller vers des révisions mineures de la toolchain LLVM. En effet, pour le moment, seules des versions majeures (3.1, 3.2 et maintenant 3.3) sont publiés. Les patches devant être backportés à la main par les packageurs (par exemple, le package llvm-3.2 de la dernière Ubuntu contient un backport du support r600).

J’espère aussi que les contributions resteront fortes. Sans partir dans un débat GPL vs BSD, certains acteurs pourraient être tentés de garder pour eux des évolutions fortes et d’autres de forker le logiciel à la manière de Webkit/Blink.

Techniquement, j’aimerais voir LLVM/Clang améliorer les performances des binaires produits pour, dans un premier temps, dépasser gcc puis se rapprocher des compilateurs Intel, le support de OpenMP (en cours de développement) et le support de Fortran.