LLVM, qui vient de sortir récemment en version 2.0, est une infrastructure de compilation libre complète ayant la particularité de mettre en avant son format intermédiaire de manière explicite, contrairement à GCC qui le garde uniquement en interne. Ainsi, il est possible de distribuer un programme sous ce format intermédiaire, qui pourra ensuite être exécuté partout. Cette approche est un peu similaire à l'approche de Microsoft avec le MSIL de .Net, mais vise ici clairement l'objectif d'avoir une performance native.
Cette représentation intermédiaire peut notamment être transformée en C, interprétée, exécutée en JIT ou compilée en natif; les performances obtenues dans ces dernier cas peuvent êtres proches de celles de GCC.
LLVM 2.0 permet désormais compiler des codes réellement complexes tels que Mozilla, Qt ou Koffice. Un backend MSIL expérimental est également fourni. LLVM, crée à l'UIUC et maintenant notamment développé par Apple fournit une infrastructure modulaire de compilation, avec une gestion souple et fine des passes de transformation, depuis le parsing jusqu'à la génération de code natif, en passant par de l'optimisation au moment de l'édition de lien.
LLVM fournit (entre autres) une bibliothèque pour manipuler et produire du code; il devient ainsi aisé de faire des systèmes de génération de code qui bénéficieront des optimisations du compilateur, telles que de l'inlining ou optimisation au moment de l'édition de lien; ainsi, Apple utilise cette approche pour OpenGL dans Leopard. De même, un projet Google Summer of Code essaye actuellement d'utiliser la génération dynamique de code dans Qemu, à la place du système actuel de génération de code ad-hoc basé sur GCC 3.
A noter qu'un des créateur et développeur principal de LLVM est Chris Lattner, qui n'était autre que le créateur de la Sabre OS Page que certains ici connaissent peut-être.
Actuellement, pour pouvoir analyser le code C/C++, LLVM utilise une version modifiée du frontend de GCC, produisant du code dans la représentation intermédiaire de LLVM. Cependant, le code de GCC n'étant pas très souple, la maintenance est difficile et l'expressivité faible. Ainsi, le passage à GCC 4.2 vient seulement de débuter.
Dans une présentation au meeting développeur LLVM (slides,vidéo), Steve Naroff explique en détail le pourquoi de la création d'un nouveau frontend. En pratique, celui-ci apportera plusieurs avantages :
- Avoir un frontend facilement réutilisable, comme par exemple pour les outils d'indexation de code des IDEs, en évitant toute incohérence entre l'interface et le compilateur ;
- Aisément concevoir des outils d'analyse et transformation de code, chose difficile à faire actuellement, particulièrement en C++ ;
- Pour les chercheurs, il sera possible de facilement modifier la syntaxe C++ afin d'expérimenter diverses idées, chose également difficile actuellement avec GCC ;
- Enfin, CFE permettra d'avoir des messages d'erreur beaucoup plus précis que GCC, et, à priori une meilleure performance sur des gros fichiers.
LLVM est un projet intéressant, ayant une approche modulaire extrêmement utile pour les outils de manipulation de code qui prolifèrent. De plus, contrairement à beaucoup de compilateurs de niche ou venant de la recherche, LLVM 2.0 est réellement utilisable dans des cas complexes réels. Comme LLVM a fait le choix du C++, le nouveau frontend ne sera probablement jamais directement intégré dans GCC; cependant, il reste très intéressant par sa souplesse et modularité et deviendra probablement un incontournable pour tout les outils de manipulation de code et autres approches expérimentales.
Aller plus loin
- Annonce de CFE (38 clics)
- LLVM Compiler Infrastructure (41 clics)
- Notes à propos de LLVM 2.0 (40 clics)
- Performances de LLVM 2.0 et gcc 4.2 (42 clics)
# Petite remarque ...
Posté par lasher . Évalué à 4.
[^] # Re: Petite remarque ...
Posté par mickabouille . Évalué à 4.
[^] # Re: Petite remarque ...
Posté par pasSteve pasJobs . Évalué à 7.
# Petite explication ?
Posté par chimai . Évalué à 2.
En gros, ça permet de créer des binaires pouvant tourner sur toutes les plate-formes, c'est ça ?
[^] # Re: Petite explication ?
Posté par reno . Évalué à 3.
Un compilateur contient grosso-modo 2 partie: un frontal qui analyse le code, et une back-end (dorsale? beurk!) qui génère le binaire pour l'ordinateur.
LLVM peut remplacer la back-end de GCC, et Apple vient de libérer un frontal indépendant de GCC, donc ça fait un nouveau compilateur 'entier' libre..
Maintenant quand a expliquer l'interet de LLVM par rapport a la backend de GCC de manière simple, la je ne sais pas faire..
[^] # Re: Petite explication ?
Posté par pasSteve pasJobs . Évalué à 2.
Ce qu'il veut dire, je pense, c'est que LLVM peut compiler directement son IR en assembleur natif (ou même en C bas niveau ou CIL/MSIL), quelle que soit la machine sur laquelle tu es, juste en spécifiant une option sur la ligne de commande.
À l'inverse, GCC est beaucoup moins modulaire, à ma connaissance il faut tout compiler à part pour construire un cross-compilateur.
Toutefois, attention : ce n'est pas très clair dans la dépèche, mais l'IR LLVM n'est portable que dans la mesure ou le front-end qui le génère s'en assure. À l'heure actuelle, l'IR produit par llvm-gcc n'est pas du tout portable[0] vu que le C/C++ ne l'est pas (taille des données dépendant de l'architecture, etc), donc il ne faut pas espérer distribuer un programme compilé via llvm-gcc vers le « bitcode » LLVM sur d'autres architectures.
[0] : http://lists.cs.uiuc.edu/pipermail/llvmdev/2005-June/004450.(...) par exemple.
[^] # Re: Petite explication ?
Posté par Pierre Palatin (site web personnel) . Évalué à 3.
Après, effectivement, il est possible de faire des trucs gore en C/C++ et il est probablement possible d'introduire des bugs de cette manière; mais il s'agit de bugs du programme, qui seraient apparus de la même manière si le programme avait été recompilé "normalement" pour une autre archi.
(après je suis pas vraiment un utilisateur de LLVM autrement que pour des tests, donc je peux me tromper; mais c'est ce qui est dit dans le thread en question & les docs et c'est cohérent avec l'interpréteur que j'ai décortiqué)
# LLVM & OpenGL/Mesa
Posté par Sebastien . Évalué à 4.
Apple utilise cette approche pour OpenGL dans Leopard
J'avais lu recemment un billet de Zack Rusin a propos de LLVM et MESA:
http://zrusin.blogspot.com/2007/05/mesa-and-llvm.html
Interessant, comme d'hab'
[^] # Re: LLVM & OpenGL/Mesa
Posté par benoar . Évalué à 4.
Par contre, dans e lien que tu files pour Mesa, Zack Rusin parle d'adapter un back-end à LLVM pour les GPU ! Ce qui me semble encore plus fou et je ne sais pas si c'est encore faisable, cf ce lien dans les commentaires :
http://lists.cs.uiuc.edu/pipermail/llvmdev/2007-May/009110.h(...)
En gros, leur code remplace le compilateur GLSL par un "optimisateur" dynamique de shader pour GPU ... ! Bon, à priori ce n'est pas encore complètement au point (i.e. le back-end pour GPU n'existe pas encore il me semble, ils n'ont qu'un back-end "soft" (CPU) pour le moment...), mais ça a l'air prometteur.
# LLVM plus rapide que GCC
Posté par loufoque . Évalué à 3.
C'est faux : le code compilé par LLVM est bien plus rapide qu'avec GCC, simplement parce que LLVM fait des optimisatons plus poussées, en particulier à l'édition de liens.
Le format intermédiaire de LLVM, de type SSA, a justement été choisi car il permettait la mise en place des tous derniers algorithmes d'optimisations issus de la recherche.
LLVM a, comme il a été dit dans un autre message, été choisi par le projet Mesa, qui va en faire des backends pour les cartes graphiques modernes. Ce qui signifie qu'à terme on pourra exécuter, en plus de GLSL, du C ou même du Python, le tout optimisé, sur son GPU.
[^] # Re: LLVM plus rapide que GCC
Posté par pasSteve pasJobs . Évalué à 4.
Preuves ? Benchs ?
L'IR du « middle-end » de GCC, Gimple, est aussi en forme SSA depuis la branche 4.x. Il a remplacé RTL pour la plupart des optimisations de haut niveau.
[^] # Re: LLVM plus rapide que GCC
Posté par Antoine . Évalué à 1.
Clique sur le dernier lien de la dépêche.
[^] # Re: LLVM plus rapide que GCC
Posté par pasSteve pasJobs . Évalué à 0.
De plus, il y a un s à Benchs, tu juges la qualité d'un compilateur à un seul bench ? Si on va par là, j'ai essayé avec nbench[0] et le dernier LLVM-GCC stable + LLVM 2.0 sont battus à plate couture par GCC 4.2.
[0] : http://www.tux.org/~mayer/linux/bmark.html
[^] # Re: LLVM plus rapide que GCC
Posté par Antoine . Évalué à 2.
Non mais c'est au moins un début de réponse à ta question. :)
[^] # Re: LLVM plus rapide que GCC
Posté par loufoque . Évalué à 1.
http://llvm.org/nightlytest/
Choisis une machine, clique sur "view details", puis sur "full test results", puis regarde la colonne GCC/LLC.
Une valeur supérieure à 1 signfie que LLVM est plus rapide.
De plus, moi qui aime bien regarder l'assembleur généré par mes programmes, je remarque qu'avec LLVM il y a une bien meilleure propagation des constantes et un meilleur inlining.
Ça inline même les fonctions virtuelles... chose dont GCC est incapable.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.