Ce projet de compilateur sous licence BSD est très modulaire et a choisi le langage C++ pour son implémentation. Il utilise actuellement le compilateur GCC du projet GNU pour analyser le code source (LLVM-GCC) mais un nouveau frontal, Clang, est prévu pour remplacer GCC à terme. Financé en grande partie par Apple, le compilateur LLVM avance vite. Moins de 4 mois après la version 2.4 voici déjà la 2.5 qui est disponible au téléchargement sur le site du projet.
Les nouveautés, même si elles ne sont pas radicales, sont néanmoins conséquentes :
- Compatibilité avec l'architecture XCore.
- LLVM 2.5 accepte désormais le code écrit en Fortran (avec l'aide du frontal GFortran issu de GCC).
- CMake est utilisé pour faciliter l'utilisation sous Windows (génération de fichiers Visual Studio).
- Support de la commande -fstack-protector qui permet de contrer les attaques par débordement de la pile.
- Les passes d'optimisation sont améliorées (en particulier en ce qui concerne le calcul sur les flottants).
- L'allocateur de registres de future génération PBQP (Partitioned Boolean Quadratic Programming) permet la fusion de registres. Il reste toutefois optionnel car le travail est loin d'être terminé.
- Le générateur de code x86 peut maintenant utiliser les instructions SSE qui autorisent les permutations de vecteurs.
Concernant le support du C et de l'Objective-C, Clang peut compiler correctement (builder) des projets très complexes comme le noyau FreeBSD ou le compilateur GCC dans sa version 4.2. la compatibilité avec l'architecture x86-64 est une nouveauté récente de Clang ainsi que le support des en-têtes précompilés.
Clang a été conçu pour être très adaptable et, dans le futur, il sera possible de l'utiliser en tant qu'analyseur statique de code pour trouver des bugs dans le code.
LLVM, du fait de son dynamisme et de sa licence BSD, commence a susciter un intérêt chez des développeurs de projets très divers. On peut citer LDC qui utilise le code de LLVM pour implémenter un compilateur pour le langage D. Le frontal libre de la société Digital Mars analyse le code source et LLVM génère le binaire (ce qui permet de ne pas utiliser le back-end propriétaire de Digital Mars).
En définitive le projet LLVM semble avoir le vent en poupe et GCC donne le sentiment de bouger moins vite que lui... mais ce sentiment est un peu trompeur puisque les deux projets n'ont pas les mêmes modes de développement.
Certes le cycle de GCC est plus long mais une nouvelle version apporte typiquement plus de nouveautés qu'une nouvelle version de LLVM. D'autre part GCC, qui a souvent été critiqué pour son conservatisme en ce qui concerne la possibilité d'ajouter des greffons, a récemment changé son fusil d'épaule et une branche spéciale a été spécialement créée pour ce projet. Le travail initial de comparaison des mécanismes possibles a commencé et nous devrions voir sous peu les premiers résultats.
La concurrence entre LLVM et GCC semble donc salutaire puisqu'elle permet une émulation et un développement plus rapide des deux projets... pour le bénéfice de tous !
Aller plus loin
- Les nouveautés de la version 2.5 (2 clics)
- Le projet Clang (1 clic)
- Télécharger la version 2.5 (3 clics)
- L'annonce de la version précédente sur linuxfr (1 clic)
- La documentation disponible (1 clic)
# Virtual Machine && Gallium3D
Posté par thedidouille . Évalué à 8.
Gallium3D utilise LLVM pour compiler les shaders, pour les cartes disposant d'unités programmables. Je ne sais pas si Apple utilise LLVM pour OpenCL.
On pourrait aussi imaginer d'utiliser LLVM pour améliorer les perfos des langages comme Python, Perl, ou php. En tout cas c'est un projet majeur, qui devrait permettre de faire des choses inattendues.
[^] # Re: Virtual Machine && Gallium3D
Posté par GeneralZod . Évalué à 8.
On en avait déjà parlé dans la news sur la sortie d'OpenCL 1.0 [1].
La réponse courte est oui. Pour les détails techniques, Apple dans sa culture du secret (à la con), n'a pas révélé grand chose. Tout ce que l'on sait, c'est qu'une implémentation d'OpenCL dans GCC, c'est pas pour demain [2], mais que l'implémentation d'Apple est très similaire à celle de la pile OpenGL dans OS X [3].
> On pourrait aussi imaginer d'utiliser LLVM pour améliorer les perfos des langages comme Python, Perl, ou php.
Il y a le projet VMKit [4]qui cherche à implémenter la JVM et la CLR au-dessus de LLVM, et PyPy s'intéresse également à LLVM [5].
[1] http://linuxfr.org/2008/12/10/24777.html
[2] http://zrusin.blogspot.com/2009/02/opencl.html
[3] http://linuxfr.org/comments/990345,1.html
[4] http://vmkit.llvm.org/
[5] http://codespeak.net/pypy/dist/pypy/doc/jit/backend.html
[^] # Re: Virtual Machine && Gallium3D
Posté par benoar . Évalué à 4.
Et pour les cartes à pipeline fixe aussi ! Je me disais que les possesseurs de "vieilles" cartes aller être oubliés, mais la conf de Stéphane Marchesin au FOSDEM du mois dernier expliquait bien comment plusieurs backends LLVM pour les différentes versions des chips NVidia ont été faits, et comment les optimisations permettaient de s'adapter (dans une certaine limite) aux "vieux" chips à pipeline fixe. Vraiment intéressant (même si ça reste très expérimental).
http://fosdem.org/2009/schedule/events/xorg_llvm_gallium
# Oui mais...
Posté par Carl Chenet (site web personnel) . Évalué à 10.
C'est plus facile de "bouger" quand il manque énormément de fonctionnalités à implémenter.
[^] # Re: Oui mais...
Posté par ribwund . Évalué à 8.
[^] # Re: Oui mais...
Posté par IsNotGood . Évalué à 5.
En passant, la version 1.0 de LLVM est sortie en novembre 2003 !
Combien de temps il faudra encore pour avoir un compilateur C++ correcte ?
Tout n'est pas aussi rose que ça même avec une architecture propre (pour le moment).
[^] # Re: Oui mais...
Posté par GeneralZod . Évalué à 3.
Attention à ne pas confondre LLVM (#backend de GCC) avec Clang (#frontend de GCC).
Si tu utilises le frontend par défaut basé sur GCC, t'as à peu de choses près un support du C++ équivalent à celui de GCC 4.2 [1], tu peux déjà compiler avec llvm (lui-même écrit en C++), Mozilla, Qt, etc ...
Quant à Clang, il reste énormément de boulot à faire au niveau du support du C++ [2], mais il apporte pas mal de fonctionnalités intéressantes en plus de celle apportés par LLVM lui-même, il s'intégre plus facilement aux environnements de développement (refactoring, IDE, outils d'analyse de sources [3], warnings plus explicites et détaillés etc ...).
Du reste, c'est un excellentissime compilateur C, Objective-C.
> Tout n'est pas aussi rose que ça même avec une architecture propre (pour le moment).
Tu fais très bien de le rappeller, même si LLVM est un projet prometteur, GCC a encore de beaux jours devant lui.
[1] modulo les exceptions qui sont pleinement supportés sur x86 et PowerPC (32/64 bits) seulement depuis llvm2.4 pour Linux et Darwin.
[2] http://clang.llvm.org/cxx_status.html
[3] http://clang.llvm.org/StaticAnalysis.html
C'est certes très jeune, c'est limité à C et Objective-C mais associé à DTrace, le développeur Mac est plutôt gâté.
http://iphonedevelopment.blogspot.com/2009/02/clang-static-a(...)
[^] # Re: Oui mais...
Posté par IsNotGood . Évalué à 4.
LLVM investit des voies qui va donner des idées à gcc, comme gcc a donné des idées à LLVM.
[^] # Re: Oui mais...
Posté par ribwund . Évalué à 2.
[^] # Re: Oui mais...
Posté par gallenza . Évalué à -2.
Bravo, encore une news de plus pour nous expliquer que LLVM roxor grave plus que GCC, quand donc cette honteuse arnaque intellectulle s'arretera-elle sur Linuxfr ???
[^] # Re: Oui mais...
Posté par patrick_g (site web personnel) . Évalué à 4.
Heu...je fais aussi les news GCC sur linuxfr alors cette attaque me semble mal fondée pour ne pas dire débile.
[^] # Re: Oui mais...
Posté par gallenza . Évalué à -3.
[^] # Re: Oui mais...
Posté par patrick_g (site web personnel) . Évalué à 4.
[^] # Re: Oui mais...
Posté par Thomas Douillard . Évalué à 4.
[^] # Re: Oui mais...
Posté par reno . Évalué à 2.
J'ignore la raison, mais la difference entre les deux est frappantes!
# et pendant ce temps...
Posté par BAud (site web personnel) . Évalué à 5.
"release early, release often" qu'ils disaient /o\
[^] # Re: et pendant ce temps...
Posté par patrick_g (site web personnel) . Évalué à 3.
# Et les perfs ?
Posté par cdeblesson . Évalué à 1.
Que donne l'exécutable généré par rapport à celui de gcc ?
D'après ce que j'ai compris en parcourant les docs du site en diagonale, le design du backend permet de manipuler la génération de binaire de manière plutôt simple et élégante.
Va-t-on voir venir des binaires exploitant au mieux les ressources des processeurs modernes, comme la panoplie SSE x.x ?
"Il paraît" que gcc est un peu mou du genou sur ce point. (je ne trolle pas c'est de l'humour, m'enfin il paraît)
[^] # Re: Et les perfs ?
Posté par patrick_g (site web personnel) . Évalué à 3.
N'importe quoi.
Un GCC 4.2 est généralement plus rapide qu'un LLVM 2.4 : http://leonardo-m.livejournal.com/73732.html
Sachant que les nouveautés de LLVM 2.5 n'ont pas énormément impactés ses performances alors que GCC, depuis la 4.2, a bien progressé (cf la news de GCC 4.4 à venir) je pense que l'écart s'est agrandi depuis ce benchmark.
[^] # Re: Et les perfs ?
Posté par windu.2b . Évalué à 2.
Je dois avouer que ce passage m'a arraché un sourire, étant donné que ladite news "se morfond en modération depuis le 18 décembre (mieux vaut préciser l'année si ça continue : 2008)"
:-)
[^] # Re: Et les perfs ?
Posté par patrick_g (site web personnel) . Évalué à 5.
Je pensais que la version 4.4 allait sortir rapidement...mais j'ai été trop optimiste...beaucoup trop optimiste !
J'aime a penser que la news mature comme du bon vin dans sa petite base SQL depuis mi-décembre ;-) Elle n'en sera que meilleure !
[^] # Re: Et les perfs ?
Posté par plic . Évalué à 2.
Quand on en est à la révision 25, on peut dire effectivement dire qu'elle est aboutie !
La faculté de citer est un substitut commode à l'intelligence -- Somerset Maugham
[^] # Re: Et les perfs ?
Posté par Victor STINNER (site web personnel) . Évalué à 2.
Je crois que personne n'aime les bugs dans les compilateurs. GCC ne peut pas se permettre de sortir avec le moindre bug critique. D'ailleurs à ce que j'ai compris, ils ont le même mode de développement que le noyau Linux : ils rajoutent des fonctionnalités puis corrigent les bugs.
[^] # Re: Et les perfs ?
Posté par cdeblesson . Évalué à 1.
Un GCC 4.2 est généralement plus rapide qu'un LLVM 2.4 : http://leonardo-m.livejournal.com/73732.html
Sachant que les nouveautés de LLVM 2.5 n'ont pas énormément impactés ses performances alors que GCC, depuis la 4.2, a bien progressé (cf la news de GCC 4.4 à venir) je pense que l'écart s'est agrandi depuis ce benchmark.
C'est pourquoi j'ai écris "il paraît". J'avais lu ça il y a quelques temps, peut être sur linuxfr, je ne sais plus. C'était à l'époque les avis de gens qui donnait l'impression de bien connaître le sujet, il faut croire que non.
Merci pour ta réponse et ton lien.
# Progression rapide
Posté par mosfet . Évalué à 7.
Cependant le gros apport de LLVM c'est l'architecture et les normes de codage, si un jour vous ne savez pas quoi faire je vous invite a regarder le code source de GCC et de me dire ce que vous en pensez. Pour faire court ca ressemble a un manuel de toutes les choses a éviter, du genre des fonction de 3000 lignes, des macros de tous les cotés qui définissent des fonctions, doc pas du tout a jour....
Si je dis ca c'est que j'ai proposé un stage concernant GCC pour améliorer le support sous windows et windows CE sur playeforme ARM, en particulier sur le support des exceptions SEH (__try, __except) car pour moi c'est vraiment ce qui manque.
Pour le moment le principe de fonctionnement des exceptions SEH est vraiment simple par contre pour l'implémentation c'est une autre histoire et je pense que mon stagiaire va pas mal galérer.
J'ai posé la question au sujet des exceptions SEH sur la ML de LLVM et on m'a répondu qu'il devrait l'implémenter dans pas trop longtemps pour le langage objective-C puis ensuite ca devrait s'étendre aux autres front-end.
Comme la déja dit quelqu'un cela pousse peut etre Gcc a bouger un peu plus vite et c'est pourquoi on voit apparaitre le système de greffons ainsi qu'une fonctionnalité dite LTO (Link Time Optimization) qui consiste a écrire en langage intermédiaire tous les objets de compilation puis d'optimiser le programme au complet seulement à la fin au moment de l'édition des liens.
Ca permet de détecter des optimisations plus globales à comparer avec une optimisation limitée au modude compilé.
J'en profite également pour passer une annonce, si quelqu'un connait Gcc et qu'il maitrise les aspects de langage intermédiaire (Gimple IR) , s'il pouvait me contacter j'aurais quelques questions.
[^] # Re: Progression rapide
Posté par BAud (site web personnel) . Évalué à 6.
comme cela se dit souvent sur irc, "don't ask to ask, just ask" ;-)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.