LLVM 3.1 et Conférence EURO-LLVM 2012

LLVM est une suite de compilation, c'est-à-dire un ensemble de bibliothèques et d'outils pour construire des compilateurs, des assembleurs, des éditeurs de liens, etc. Et quand on parle de LLVM, on parle forcément de Clang, le compilateur C/C++/ObjectiveC/ObjectiveC++ attitré du projet LLVM. Clang, par rapport à GCC, compile plus vite mais génère du code moins rapide, le vrai intérêt de Clang réside dans la clarté des messages d'erreurs.

La seconde partie de cette dépêche détaille les nouveautés de la version 3.1 de LLVM et Clang, sortie le 22 mai 2012 et propose un compte rendu de la toute première conférence Euro-LLVM (avril 2012).

LLVM et Clang 3.1 sont téléchargeables ici et là respectivement (les utilisateurs de Debian Sid n'ont évidemment qu'à faire un apt-get install llvm-3.1 clang)

[NDA: un grand Merci à rewind qui a rédigé, entre autres, toute la couverture de la conf Euro-LLVM. Merci également à patrick_g, reno, Nÿco, baud123 et Sylvestre Ledru pour leurs corrections et leurs précisions.]

Sommaire

• Clang
  • Nouveaux warnings
    • -Wdangling_else
    • -Wstrncat-size
  • Amélioration de la prise en charge de C++11 :
  • Prise en charge de C11
• Nouvelles optimisations
  • Polly wants a cracker
  • Déroulage de boucles dynamique
  • Placement de blocs de base
  • Back-end x86 et x86-64
• Euro-LLVM 2012
  • Introduction
  • Autovectorization with LLVM
  • Refactoring C++ with Clang
  • MCJIT
  • Generating Serialisation Code with Clang
  • Garantir que MC est correct même pour ARM
  • lld - the LLVM Linker
  • Reducing dynamic compilation latency
  • Compilation de Linux par LLVM
  • Tablegen Deep Dive
  • Improving Performance of OpenCL on CPUs
• Pendant ce temps, de l'autre côté de la manche
• Et pour l'avenir ?

Clang

Clang est le front-end officiel de LLVM pour les langages de la famille de C. Les premiers langages pour lesquels il a atteint un niveau de « production » sont C et Objective-C (on voit là l'influence de la marque à la pomme qui a sponsorisé ce projet).
À partir de 2010, la prise en charge de C++ a progressé pour devenir excellente. La version 2.8 en octobre 2010 a apporté la compatibilité avec le standard C++03. Depuis, les efforts ont continué et Clang est désormais à la pointe en ce qui concerne le tout nouveau C++11.
Clang se démarque de gcc par la précision et la qualité de ses diagnostics, mais aussi par sa modularité : il est possible de créer ses propres outils d'analyse de code grâce à la libclang.

Nouveaux warnings

Clang est réputé pour la qualité de ses diagnostics. Cette fois-ci, plusieurs nouveaux warnings ont été ajoutés permettant une analyse encore plus précise du code source. En particulier, on notera :

-Wdangling_else

Lorsque deux if successifs sont suivis par une instruction else (dangling else), la syntaxe C/C++ prévoit que le else s'applique au if le plus imbriqué ; mais une mauvaise indentation peut induire en erreur le relecteur :

  if (foo)
    if (bar) std::cout << "case 1\n"; 
  else
    std::cout << "case 2\n";

clang++ avertit l'utilisateur en lui propose de lever l'ambiguïté :

dangling.cpp:8:3: warning: add explicit braces to avoid dangling else
      [-Wdangling-else]
 else std::cout << "case 2\n";
 ^

-Wstrncat-size

Les fonctions standard C strcpy et strcat permettent respectivement de copier et de concaténer des chaînes de caractères, mais ne permettent pas de s'armer contre des débordement de buffer provoqués par une trop grande chaîne source.
Pour remédier à cela, la bibliothèque C propose également strncpy et strncat, prenant toutes deux un argument supplémentaire de type size_t qui spécifie la taille des données à copier.
Hélas, trois fois hélas, si on peut la plupart du temps entrer la taille du buffer de destination pour strncpy, il en va autrement pour strncat. Il faut bien évidemment songer à retrancher la taille utilisée par les données déjà présentes.
Un coup d'œil sur le code historique de votre entreprise vous convaincra pourtant que les codes du type :

 strncat(dest, src, sizeof(src));

ou

 strncat(dest, src, sizeof(dest));

sont relativement répandus.
Clang repère ce type d'erreur et fidèle à son habitude, vous propose une solution :

strncat.c:8:22: warning: the value of the size argument in 'strncat' is too
      large, might lead to a buffer overflow [-Wstrncat-size]
  strncat(dest, src, sizeof(dest));
                     ^~~~~~~~~~~~
strncat.c:8:22: note: change the argument to be the free space in the
      destination buffer minus the terminating null byte
  strncat(dest, src, sizeof(dest));
                     ^~~~~~~~~~~~
                     sizeof(dest) - strlen(dest) - 1
1 warning generated.

Tout n'est pas parfait et force est de constater que clang reste muet quand le code précédent est remplacé par

strncat(dest, src, strlen(src));

Amélioration de la prise en charge de C++11 :

Les développeurs de clang ont encore amélioré la prise en charge de C++11. Les nouveautés les plus intéressantes sont :

• les listes d'initialisation :

std::vector<int> v{1, 2, 3, 4, 5};

• les lambda expressions :

 std::transform(v.begin(), v.end(), v.begin(),
                 [](int x){return 2 * x +1;});

• les types littéraux définis par l'utilisateur :

Ces types peuvent avoir des utilisations intéressantes, comme par exemple la vérification statique de l'homogénéité du calcul scientifique. On peut dorénavant définir assez facilement un système d'unités et écrire des expressions du type:

Speed delorean 157715.712_m / 3600._s;//valide
Speed caddie 2_m;//erreur de compilation

Voir la keynote de Bjarne Stroustrup à la conférence « C++ Going Native 2012 » pour les détails de l'implémentation.

• Types atomiques

Les types pour les opérations atomiques, essentielles en programmation concurrente, ont été implémentés dans clang. En conséquence, il semblerait que la libc++ ait désormais une implémentation virtuellement complète de C++11.

Fait marquant, pour la première fois, llvm propose une prise en charge plus complète que gcc du standard C++11. Clang est donc à l'heure actuelle ce qui se rapproche le plus d'un compilateur parfaitement compatible C++11. Les « exclusivités » de clang++ par rapport à gcc sont :

• surcharge des fonctions membres pour les rvalues
• mots clés alignas et alignof qui permettent de forcer un alignement encore plus strict que ce que fait C++ par défaut :

struct S//taille 4 sans "alignas", taille 8 avec
{
   short s0;
   short alignas(int) s1;//offset de 2 octets sans alignas, 4 octets avec
};

• l'en-tête <regex> pour la bibliothèque d'expressions rationelles de la bibliothèque standard dans libc++.

Prise en charge de C11

Alors que le concurrent propriétaire fait sa chochotte préfère se concentrer sur le langage C++, clang propose une prise en charge de la norme C99 quasi-exemplaire. En outre, bien que Le standard C11 soit à peine publié, l'équipe de clang a déjà commencé à le prendre en charge. Pour cette version, les développeurs ont implémenté les structures anonymes décrites dans la dépêche sortie pour la publication du standard. Ceci s'ajoute aux mots-clés alignas, generic ainsi qu'aux static_assert déjà présents dans clang 3.0

Nouvelles optimisations

Polly wants a cracker

Pour la version 3.1, LLVM se dote officiellement d'un module d'optimisation polyédrale, au joli nom de Polly. et développé par Tobias Grosser, actuellement doctorant à l'ENS. Ce garçon n'en est pas à son coup d'essai puisqu'il travaille également sur la branche Graphite qui a été incorporée dans la version 4.4 de GCC (voir la dépêche de 2009 qui propose une description précise de ce type d'optimisation). Si les résultats sont à la hauteur, on peut s'attendre à des améliorations sensibles des performances dans certains calculs matriciels.

Déroulage de boucles dynamique

Une technique classique pour optimiser les boucles est de les dérouler pendant la compilation, au prix d'une plus grande quantité d'instructions. LLVM implémente maintenant le déroulage de boucles dynamique, c'est-à-dire quand le nombre d'itérations n'est pas connu au moment de la compilation.

Placement de blocs de base

LLVM 3.0 avait permis la prise en charge de méta-données sur les branches qui permettaient d'attribuer des poids différents suivant les probabilités. Cela se traduit concrètement dans un code C par l'extension __builtin_expect() qu'on retrouve également dans GCC.

Dans LLVM 3.1, un algorithme de placement des blocs a été implémenté prenant en compte ces informations. Cela ouvre la voie à des outils similaires à gprof qui vont permettrent d'annoter le code statiquement pour permettre un meilleur agencement des blocs et donc de meilleures performances.

Back-end x86 et x86-64

Pour la version 3.0, LLVM avait déjà proposé la prise en charge des nouvelles instructions Advanced Vector Extensions (AVX), disponibles sur Intel Sandy/Ivy Bridge et sur les AMD Bulldozer. LLVM 3.1 améliore grandement cette prise en charge et ajoute celle des instructions AVX2, prévues sur les futurs processeurs Haswell d'Intel.

Euro-LLVM 2012

Les 12 et 13 avril dernier a eu lieu la première conférence européenne dédiée à LLVM. Organisée par ARM avec un soutien financier de Google et Qualcomm, de nombreux exposés ont été présentés ainsi que des ateliers pratiques autour de LLVM. Ces présentations permettent d'entrevoir le futur de LLVM ainsi que les avancées déjà intégrées pour certaines.

Introduction

Le court exposé d'introduction de Lee Smith (ARM) permet de savoir pourquoi son entreprise s'intéresse à LLVM (attention, appeaux à trolls). En fait, c'est surtout les défauts de GCC qui sont mis en avant : le code de LLVM, outre le fait qu'il soit «open source», est plus jeune donc plus facile à travailler ; LLVM a moins de contraintes techniques contrairement à GCC qui doit gérer des choix anciens ; LLVM est un meilleur framework pour fabriquer des outils d'analyse ou des langages dédiés. Autres qualités de LLVM, plutôt techniques : il peut émettre du code pour des processeurs spécialisés (DSP) propriétaires, il est capable de générer du code JIT, il est capable de prendre en charge OpenCL. Enfin, sa licence est «non-virale».

Autovectorization with LLVM

Hal Finkel du Argonne National Laboratory explique les progrès qui ont été accomplis dans l'autovectorisation. Il s'agit de transformer des couples d'instructions simples en une instruction plus complexe issue des diverses extensions disponibles (MMX, SSE*, AltiVex, NEON, etc). Comme LLVM gère depuis très longtemps dans sa représentation intermédiaire les vecteurs de registres ainsi que les opérations de base associées (addition, multiplication, etc), les différents backend qui génèrent du code machine peuvent déjà générer ces instructions. Le travail peut donc s'effectuer au niveau de la représentation intermédiaire et profiter à toutes les architectures.

Par exemple, si on a ces deux instructions simples :

%A1 = fadd double %B1, %C1
%A2 = fadd double %B2, %C2

On peut les transformer en une seule instruction en utilisant un vecteur de registre :

%A = fadd <2 x double> %B, %C

Refactoring C++ with Clang

Manuel Klimek de Google montre qu'on peut rendre C++ très amusant à l'aide d'outils adaptés. Un travail a commencé pour fournir des briques de bases et des outils pour manipuler du code C++. Les outils envisagés sont très connus mais souvent imparfaits. Ainsi Google envisage de créer un formateur de code, clang-format, qui permettrait de reformater du code selon des règles prédéfinies. Là où indent ou astyle se contentent de correction stylistique, clang-format pourrait carrément, grâce à la puissance de LLVM, s'attaquer à la syntaxe, en modifiant par exemple la casse du nom d'une fonction, dans sa définition et partout où elle utilisée ! Autre outil, clang-lint permettrait de vérifier le code à la recherche d'erreurs classiques, mais également de les corriger interactivement à la volée ! Le travail sur les bibliothèques de base a déjà commencé tandis que les outils sont encore à construire, mais sont très prometteurs.

MCJIT

Eli Bendersky d'Intel présente un débuggueur de code JIT basé sur LLVM. À noter qu'il travaille dans l'équipe OpenCL d'Intel.

Generating Serialisation Code with Clang

Wayne Palmer de Barclays Capital utilise Clang pour générer du code de sérialisation automatiquement. Dans le cadre d'une bibliothèque d'analyse quantitative utilisée par sa banque pour calculer les risques, un travail a été mené pour pouvoir générer le code de sérialisation permettant de transmettre des structures à travers le réseau, plutôt que de l'écrire à la main. Ils ont remplacé une solution basée sur Doxygen (!!!) pour une solution basée sur LLVM. Le développeur peut ainsi annoter son code C++ pour déclarer si une classe doit avoir un code de sérialisation ou pas. La principale difficulté est alors de générer le code de sérialisation au bon endroit pour qu'il soit compilé une seule fois.

Garantir que MC est correct même pour ARM

Richard Barton de ARM explique comment il a amélioré la génération de code ARM de LLVM. La génération de code dans LLVM a lieu dans un framework appelé MC pour Machine Code. Comme tout le reste dans LLVM, ce framework est très modulaire, ce qui lui permet de construire toute une série d'outils relativement simplement : assembler, désassembleur, etc. Ici, l'idée est de faire une vérification exhaustive de tous les opcodes de toutes les variantes de processeurs ARM en comparant les résultats de LLVM MC avec une implémentation de référence propriétaire de ARM. Cela représente près de 7 billions (7¹² ) de combinaisons possibles ! Heureusement, cet ensemble de test a été réduit pour pouvoir être exécuté en temps raisonnable. Les premiers résultats montrent qu'à peu près 10% de toutes les instructions du Cortex-A8 sont mal encodés par LLVM-MC. 14 patchs ont déjà été soumis et d'autres devraient suivre.

lld - the LLVM Linker

Michael Spencer de Sony Computer Entertainment America présente LLD, un éditeur de lien basé sur LLVM. Le but de lld est de remplacer les éditeurs de liens fournis avec le système (GNU ld ou GOLD pour Linux, ld64 pour MacOSX, link.exe pour Windows) en offrant un éditeur de lien performant, portable et surtout, qui permette de faire de l'édition de lien croisée de manière sûre. Le projet ne fait que démarrer.

Reducing dynamic compilation latency

Igor Bohm de l'University of Edinburgh utilise un ou plusieurs threads « auxiliaires » qui réalisent une compilation JIT pour optimiser les performances d'une machine virtuelle.

Compilation de Linux par LLVM

Mark Charlebois de QuIC présente les avancées de la compilation de Linux par LLVM. Le principal problème est que Linux dépend beaucoup de GCC, que ce soit à travers certains comportements comme la réaction par rapport à des options de compilations présentes ou non, ou par rapport à ces options de compilations non présentes dans LLVM, ou encore par rapport à des extensions du langage comme les tableaux de taille variable dans des structures ou les fonctions imbriquées. Sans même parler des incompatibilités spécifiques à certaines architectures comme ARM. Heureusement, tout cela est documenté pour permettre un suivi, et des patchs sont soumis.

Rappelons que dans ce même effort, Debian recompile régulièrement toute l'archive avec Clang.

Tablegen Deep Dive

Reed Kotler de MIPS présente un outil interne de LLVM : Tablegen. Cet outil, assez mal documenté, prend en entrée des fichiers de description et en ressort des morceaux de code. La syntaxe des fichiers de description est complètement générique, un peu à la manière d'XML. Pour la sortie, il est possible d'écrire des générateurs pour des tâches particulières. LLVM se sert massivement de Tablegen au niveau des générateurs de code pour documenter les registres, les instructions, les informations des architectures et de leurs variantes, etc. Ainsi, une même source d'information sert à générer diverses parties sans redondance inutile : assembleur, désassembleur, encodeur, décodeur. Cette présentation permet d'approcher un peu plus cet outil et est surtout l'occasion de lancer un effort de documentation pour permettre à Tablegen de vivre sa propre vie.

Improving Performance of OpenCL on CPUs

Ralf Karrenberg et Sebastian Hack de Saarland University montrent comment utiliser LLVM pour exécuter les kernels OpenCL sur des processeurs multicœurs actuels. Les performances sont au rendez-vous puisque l'implémentation actuelle surpasse les SDK d'Intel et d'AMD. Avec les autres avancées au niveau de l'autovectorisation, il sera bientôt possible d'avoir des kernels extrêmement performants.

Pendant ce temps, de l'autre côté de la manche

Pour ceux que LLVM intéresse, voire passionne, ou simplement ceux qui veulent boire un verre en discutant d'arbres de syntaxe abstraits, l'Initiative de Recherche et Innovation sur le Logiciel Libre (IRILL) organise l'évènement LLVM Social sur Paris. La prochaine session aura lieu ce samedi 26 mai. L'horaire et l'emplacement seront publiés incessamment sur le site d'IRILL.

Et pour l'avenir ?

Grâce à sa licence permissive modularité et sa modernité, LLVM a su générer une myriade de projets qui en font aujourd'hui un des acteurs les plus dynamiques dans le monde du développement libre.
Plus de 12 ans après sa fondation, c'est aussi l'heure de la maturité pour cette suite de compilation : de plus en plus d'industriels de premier plan (Google, Apple …) utilisent LLVM en développement ou en production. Les derniers benchmarks de Phoronix montrent que l'écart de performance entre le code généré par gcc et llvm se resserre progressivement.
Parallèlement, le projet Free-BSD annonce que clang deviendra le compilateur C/C++ par défaut pour la version 10 … coïncidence ?

Aller plus loin

• Notes de version de llvm 3.1 (77 clics)
• Notes de version le clang 3.1 (55 clics)
• The LLVM Compiler Infrastructure (31 clics)
• Site Web de LLVM (53 clics)
• Site Web de Clang (46 clics)