La version 2.9 de LLVM vient de sortir et a été annoncée par Chris Lattner le 6 avril !
Pour ceux qui se posent encore la question, LLVM est une suite de compilation concurrente de GCC, sous licence UIUC (semblable à BSD), qui a pour but de produire des briques de bases modulaires pour construire toute sorte de programmes : compilateurs, debugger, assembleur, etc. L'aspect hautement modulaire permet également de pouvoir travailler sur une petite partie et d'en faire bénéficier toutes les autres. C'est notamment le cas des optimisations : en effet, LLVM utilise une représentation intermédiaire (IR) parfaitement spécifiée et les optimisations se font sur cette représentation. Et ce n'est qu'un des nombreux avantages de LLVM.
Cette version 2.9 permet de consolider plein d'aspects de LLVM. Parmi les nouveautés principales, on notera :
- la génération de code a été améliorée, en particulier pour l'architecture ARM ;
- l'optimisation au moment de la liaison (LTO) a été améliorée également ;
- un nouvel allocateur de registre a été écrit, mais n'est pas activé par défaut pour cette sortie ;
- l'infrastructure Machine Code est désormais utilisée par défaut pour produire du code objet directement (plutôt que de passer par un assembleur externe) ;
- Clang, le compilateur C/C++/Objective-C/Objective-C++ gère le C++0x de mieux en mieux, avec l'ajout des rvalue references et des variadic templates ;
- LLDB, le débugger du projet LLVM, atteint un certain stade de maturité alors que ce n'était qu'un projet larvaire à la dernière sortie.
LLVM 2.9
Parmi les autres nouveautés concernant les projets LLVM pour cette sortie :
Clang
Clang a fait de gros progrès depuis la dernière fois et est considéré comme un outil de production. Il prend en charge une partie de plus en plus importante de la future norme C++. Il est aussi capable de compiler un noyau Linux (avec cependant quelques limites, notamment au niveau de l'API crypto qui utilise des extensions GNU) et la machine virtuelle Java HotSpot.
DragonEgg
DragonEgg est un greffon pour GCC qui remplace le backend de GCC par celui de LLVM. Ce projet se stabilise mais n'est pas encore considéré comme suffisamment mûr. Pour cette sortie, des améliorations ont été apportées qui permettent de compiler de plus en plus de code Fortran, Objective-C, Objective-C++ et Java, sans qu'on sache si le code produit fonctionne bien comme prévu.
Changement de licences
Les deux projet compiler-rt (qui fournit des fonctions pour certaines instructions qui n'existeraient pas sur certaines architectures, comme par exemple la conversion d'un double en entier signé 64 bits) et libc++ (une bibliothèque standard C++ complète écrite pour C++0x) sont maintenant sous double licence UIUC (comparable à BSD) et MIT.
Le futur : LLVM 3.0
La prochaine version de LLVM sera la 3.0. Le principal changement sera l'abandon définitif de la branche llvm-gcc (le front-end de GCC avec le backend de LLVM) au profit d'une part de Clang et d'autre part de DragonEgg qui a la même utilité.
On peut aussi penser que le système de type de LLVM va être revu. Des discussions ont eu lieu et Chris Lattner a produit une note pour décrire les limites du système actuel et ce qu'il faudrait faire pour le modifier. Les types dans LLVM sont traités de manière un peu particulière. En effet, c'est la structure du type qui est importante et pas son nom. Ceci a l'avantage de simplifier certaines comparaisons (une simple égalité de pointeur suffit) mais génère beaucoup de travail car il faut s'assurer en permanence de cette propriété (et donc comparer les structures des types). L'idée ici est de permettre de faire des distinctions entre type qui ont la même structure mais pas le même nom, de manière à simplifier certaines parties critiques du code d'une part, et la vie des utilisateurs qui veulent construire des types qui font référence à eux-même (comme des types de listes chaînées par exemple).
L'autre point qui pourrait évoluer est la manière dont sont gérées les architectures-cibles. Dans GCC et certains outils GNU, les cibles sont représentées à l'aide d'un triplet de la forme i686-pc-linux-gnu. Cependant, cette notation n'est pas normalisée et ne résout pas de nombreux problèmes. Chris Lattner a proposé une nouvelle manière de spécifier les cibles qui pourrait donner par exemple x86-64.le.linux.elf.unknown ou arm.le.linux-eabi.elf.cortex-a8.
LLVM Developers' Meeting
Même s'il est passé inaperçu sur LinuxFR, c'est le bon moment pour parler du LLVM Developers' Meeting qui s'est déroulé le 4 novembre 2010. Plusieurs projets internes et externes ont été présentés, que ce soit par des développeurs de LLVM ou par des grands noms comme Google, AMD, Apple, CERN, Sony, Ericsson, etc. C'est l'occasion pour les utilisateurs de LLVM de remonter leurs contraintes et leur demandes à l'équipe de LLVM. On notera en particulier :
- AMD OpenCL Compiler - Using LLVM to produce a cross-platform heterogeneous compiler tool chain par Micah Villmow, AMD Inc. : présentation et vidéo
- Implementing Include-What-You-Use using clang par Craig Silverstein, Google ou comment utiliser Clang pour n'inclure que les en-têtes nécessaires dans un fichier C et donc accélérer le temps de compilation : présentation et vidéo
- The Crack Scripting Language par Michael Muller, Google, un nouveau langage de script créé par un employé Google sur ses 20% de temps libre : présentation et vidéo
- et plein d'autres…
Aller plus loin
- The LLVM Compiler Infrastructure (170 clics)
- Clang (51 clics)
- LLVM 2.9 Release Notes (62 clics)
- LLVM 2.8 sur linuxfr.org (43 clics)
- LLVM 2.7 sur linuxfr.org (25 clics)
# IR
Posté par ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) . Évalué à 10.
Y a-t-il vraiment des compilateurs qui ne procèdent pas ainsi ? Par exemple, à l'époque où j'avais vaguement regardé le code de GCC, il m'avait semblé que celui-ci utilisait plusieurs représentations intermédiaire (Gimple, generic …) permettant diverses optimisations. Et j'imagine qu'il en est de même pour la grande majorité des compilateurs multi-langages et multi-cibles. Serait-ce une erreur ?
Et si non, ne serait-il pas intéressant d'insister plutôt sur les particularités de la représentation intermédiaire de LLVM qui en font l'un de ces avantages ? Au lieu de cet argument qui semble tout droit sortie de chez un concessionnaire : « regardez, elle a 4 — oui bien quatre — superbes roues ; avec des jantes ; magnifique ; ne les vaut-elle pas ces 80.000 € … »
« IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
[^] # Re: IR
Posté par X345 . Évalué à 10.
Nous n'avons peut-être pas lu la phrase de la même manière mais personnellement, je comprends que l'avantage de LLVM est que sa représentation intermédiaire est parfaitement spécifiée et que les optimisations se font toutes dessus. Peut être que la représentation intermédiaire d'autres compilateurs n'est pas vraiment spécifiée et qu'ils des optimisations avant de de la produire. Si je ne me trompais pas, ce serait donc bien quelques avantages spécifiques de la représentation intermédiaire de LLVM.
[^] # Re: IR
Posté par TImaniac (site web personnel) . Évalué à 3.
L'objectif de LLVM est d'avoir effectivement un backend réutilisable : une licence très permissive, une VM (définie par sa représentation intermédiaire) clairement définie et documentée.
Tout l'inverse de GCC : les représentations intermédiaires sont là pour des raisons purement technique. GCC reste politiquement monolithique : pas de lib sous licence permissive (GPL est clairement non friendly pour une bonne partie de l'industrie), pas de volontée d'avoir une telle lib "backend" réutilisable par tous.
En gros tous ceux qui sont enmerdé par la politique de GCC misent sur LLVM.
[^] # Re: IR
Posté par ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) . Évalué à -3.
Oui, même les durs de la feuille comme moi ont bien compris le problème que pose la licence — trop respectueuse des libertés des utilisateurs — de GCC à certains groupements d'intérêts plus orientés « real politic » et parfois moins sourcilleux que la FSF quant aux droits de leurs constituants (les machines organiques qui correspondent aux cases de l'organigramme) et clients. Néanmoins, la question ne portait pas sur ce sujet. Contrairement à la réponse qui semble ne reprendre les éléments interrogés que pour mieux les éluder, et s'étale sur cette différence de licence qui a déjà si souvent fait l'objet de polémiques.
Comme Xion345 et visiblement de nombreux autres, je m'interroge réellement sur le sens à donner à :
Ou encore à vos :
Car dans votre commentaire comme dans le journal, cela reste ambiguë. Un peu comme une manière de dire que le backend de gcc ne serait pas réutilisable (!) ou que gcc ne serait pas bien documenté. Le second point étant certainement une question de goût et de jugement personnel dont chacun est libre.
Toujours est-il que j'attends avec impatience qu'un connaisseur puisse nous apporter une réponse éclairée sur le sujet.
« IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
[^] # Re: IR
Posté par GeneralZod . Évalué à 10.
Jusqu'à récemment, GCC était conçu de sorte qu'il soit difficile de réutiliser autre part des morceaux du compilateur (comme le backend) sans devoir l'intégrer directement au tronc (pour éviter la "propriétarisation" du code). Ça a toujours été affirmé haut et fort par RMS et le projet GNU, rien à voir avec de la médisance.
[^] # Re: IR
Posté par ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) . Évalué à 3.
Tout à fait. Mais ça n'a juste rien à voir avec la question posée. Donc insister sur ce point ne fait pas avancer le schmilblik. Et apparemment préciser que la question posée est sans rapport avec ce sujet ne sert à rien également puisque voici encore une réponse qui revient là-dessus. Dommage.
« IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
[^] # Re: IR
Posté par Gniarf . Évalué à 2.
allez, je suis très pédagogue aujourd'hui :
[^] # Re: IR
Posté par beagf (site web personnel) . Évalué à 10.
Ton ironie passe mal. Tu sembles insinuer que les licences BSD, MIT ou équivalent sont moins bien que la reine GPL qui assure plein de choses à l'utilisateur. Le problème est pourtant bien réel, la GPL ne permet de réutiliser une bibliothèque dans un projet qui n'est pas open source. Il y a de développeurs que cela ne gène pas et il y en a d'autres qui ne veulent pas imposer cette restriction à leurs utilisateurs.
Chacun son choix et tu n'as pas à le critiquer.
Ce n'est pas une question de goût où autre, le backend n'était, au moment ou LLVM à débuter, absolument pas réutilisable et ce de manière volontaire. Le changement de position de RMS et de la FSF à ce sujet est d'ailleurs sûrement en grande partie dû à LLVM.
Quand à la documentation des représentation intermédiaires, c'est à peu près la même chose. Il n'y a pas grand chose et surtout elle à été définie uniquement selon les besoins et l'architecture de GCC. Ce n'est pas une critique ici mais un choix technique.
La grosse différence est là : les représentation intermédiaire dans GCC ne sont qu'un moyen technique de faire la compilation, s'il y a avait d'autres méthode aussi efficaces ils auraient pus tout autant les choisir. Elles évoluent en fonction des besoins de GCC sans ce préoccuper du reste du monde car seul GCC les utilises, bref, c'est un truc très bien pour GCC mais absolument inutilisable pour le reste du monde.
Dans LLVM, au contraire, la représentation intermédiaire à été conçue et clairement définie de manière à être un outil de partage entre de nombreux outils. Elle est donc parfaitement définie et peut donc être facilement utilisée par n'importe qui et à été conçue de manière à couvrir le plus grand champs d'application possible, pas uniquement un seul compilateur.
L'approche de GCC à l'avantage d'avoir un truc plus adapté à un outils en particulier et que l'on peut faire évoluer facilement quand le besoin s'en fait sentir, alors que l'approche de LLVM permet de faire fonctionner ensemble de nombreux programmes sans problème mais au d'une évolution plus lente.
Il faut bien voir que les deux approches ont des objectifs différents et que dans le cas de GCC, le reste du monde s'en contre tape de savoir qu'il y a une représentation intermédiaire puisque de toute façon elle est inutilisable en dehors de GCC.
[^] # Re: IR
Posté par zul (site web personnel) . Évalué à 4.
Tu devrai regarder la liste des projets qui targettent aujourd'hui la représentation intermédiaire de llvm, et te demander pourquoi aucun projet n'avait eu cette brillante idée avec la représentation intermédiaire de gcc (et je parle de projets fermés fermés comme python, ruby, ghc ...) (pour des problèmes techniques et de licenses).
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 3.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: IR
Posté par lasher . Évalué à 6.
Pas seulement. GCC a subi de grosses transformations, entre le GNU C Compiler et sa fusion avec egcs, l'adoption de GIMPLE comme représentation intermédiaire, directement inspirée de SIMPLE de chez Open64, etc. À chacun de ces moments, le comité aurait pu essayer de rendre les choses plus accessibles au commun des mortels.
... Ou pas. Et c'est bien « pas » qui s'est produit.
[^] # Re: IR
Posté par TImaniac (site web personnel) . Évalué à 2. Dernière modification le 08 avril 2011 à 21:46.
Ben tu vois, c'est pas du tout ambigüe puisque t'as tout compris :)
GCC a tout fait pour rester monolithique :
A l'inverse, LLVM fait tout pour être réutilisé par le plus grand nombre. Et ses contributeurs sont d'ailleurs ses premiers utilisateurs.
[^] # Re: IR
Posté par lasher . Évalué à 10.
L'immense avantage de LLVM sur GCC est sa modularité. Tous les compilateurs modernes ont bien trois « étages »: le front-end, qui fait l'analyse syntaxique et sémantique du code écrit par le programmeur; le middle-end, comme par exemple GIMPLE pour GCC, l'IR de LLVM, SIMPLE pour Open64, etc.; et le back-end, qui transforme la représentation intermédiaire en code exécutable pour une machine-cible donnée.
Cela étant dit, GCC est notoirement connu pour volontairement/politiquement mélanger informations du front-end et informations du back-end, pour éviter que des « méchants » « volent » les différents front-ends de GCC et y branchent leurs propres middle- et back-ends. Bouh, vilains. À cause de cela, beaucoup de programmeurs se sont détournés de GCC. Comprenons-nous bien: un compilateur est, par définition, quelque chose de difficile à modifier sans tout casser. Mais avec la politique suivie pour GCC, il est encore plus difficile de rentrer dans le code. Heureusement, le comité derrière GCC a enfin accepté (relativement récemment) de permettre l'utilisation de plugins (les raisons des refus précédents étant eux aussi politiques, liés à la peur des grands méchants qui pourraient créer des plugins propriétaires, au code fermé et utiliser le résultat du travail de GCC sans participer, tout ça).
Le fait est que LLVM est plus simple à utiliser et étendre que GCC. C'est le compilateur que mon équipe a choisi pour notre projet de développement (et oui, nous sommes des gentils, donc quand nous voyons des bugs qui ne sont pas liés à nos extensions à proprement parler, nous remontons l'info).
Ah ben c'est vrai. La doc de LLVM (tant commentaires dans le code que sur le site web) reste limitée, et il faut faire pas mal d'efforts pour rentrer dans le code. GCC est dix fois pire de ce point de vue. La doc de GCC est juste atroce.
[^] # Re: IR
Posté par djano . Évalué à 5.
Pourtant je trouve que si tu lis bien les commentaires de Xion345 et Timaniac, tu as bien ta réponse. Certes il ya des hors sujet, mais le fond y est.
GCC marche comme ceci:
frontend -> RI RTL -> RI Generic -> RI GIMPLE -> backend -> ... (je ne sais plus trop bien après. Génération de code spécifique a la cible (OS, CPU) je suppose?)
Certains frontend GCC sont connus pour faire des optimisations sur le code lu directement dans le front end avant meme d'arriver a une représentation intermédiaire. C'est clairement un problème lorsque l'on veut réutiliser un frontend pour faire de l'analyse de code ou des transformations de code (reindentation automatique, etc.).
A ma connaissance GCC n'a pas spécification sur ses différents RI, ce qui rend la tache ardue pour qui veut contribuer a GCC. Cette barrière a l’entrée est assez problématique. Je me rappelle avoir lu qu'ils avaient des problèmes pour recruter des contributeurs, même si certaines personnes (Tara Glek) ont trouvé le code de GCC plus facile a comprendre que ce qu'on avait pu leur dire initialement. Donc LLVM spécifiant la RI, il est plus facile de rentrer dans le code après avoir lu cette spec.
Voila en quoi c'est un avantage d'avoir une RI bien spécifiée et de n'appliquer les optimisations que sur celle-ci.
[^] # Re: IR
Posté par Matthieu Moy (site web personnel) . Évalué à 10.
La licence de GCC est tellement respectueuse de la liberté des utilisateurs, que quand j'ai écrit un outil qui utilise GCC et uniquement du logiciel libre, sa licence m'a interdit de diffuser mon outil sous forme compilée en plus des sources, à cause d'incompatibilités de licences (entre GPL et SystemC) ...
La licence de GCC m'a fait chier moi pendant ma thèse, elle fait chier les gens de BSD, ... On entre dans la case de tes groupes d'intérêts ?
GCC n'est pas modulaire, c'est un fait. Essaye de récupérer juste le back-end, ou juste le front-end de GCC (par exemple, faire un outil qui récupère une des représentations de GCC mais qui n'embarque pas le générateur de code). J'ai essayé, beaucoup d'autres gens ont essayé, et a peu près tous te diront que c'est un merdier terrible.
Ça évolue côté GCC. Depuis GCC 4.5, on a un système de plugins qui fait que GCC a une API externe et que ça devient possible de récupérer une représentation intermédiaire sans patcher GCC, alors que RMS s'y était toujours opposé pour des raisons non-techniques. J'ai d'ailleurs du mal à croire à une coïncidence quand je vois que GCC a pris ce virage pile au moment où LLVM devenait crédible. RMS a cédé parce qu'il ne voulait pas perdre d'utilisateurs au profit d'un logiciel non-GNU avec une licence non-GPL ...
Sinon, techniquement, un avantage de la représentation intermédiaire de LLVM, c'est qu'elle est disponible à la fois sous forme de structure de données, de texte (un peu comme de l'assembleur), et de fichier binaire, avec des moyens de passer de l'un à l'autre facilement.
[^] # Re: IR
Posté par Nicolas Boulay (site web personnel) . Évalué à -4.
La licence de GCC est tellement respectueuse de la liberté des utilisateurs, que quand j'ai écrit un outil qui utilise GCC et uniquement du logiciel libre, sa licence m'a interdit de diffuser mon outil sous forme compilée en plus des sources, à cause d'incompatibilités de licences (entre GPL et SystemC) ...
Là j'ai beaucoup de mal à te croire. La licence de la lib runtime de GCC est assez permissive pour ne pas forcer l'usage de la GPL dans le code généré. On peut tout à fait faire (compiler) des logiciels proprio avec GCC encore heureux !
GCC RUNTIME LIBRARY EXCEPTION
"La première sécurité est la liberté"
[^] # Re: IR
Posté par TImaniac (site web personnel) . Évalué à 4.
Il a dit un outil qui utilise GCC, pas un outil dont les sources sont compilées avec GCC.
[^] # Re: IR
Posté par Nicolas Boulay (site web personnel) . Évalué à -5.
SystemC est une lib C++. Ce n'est pas "un logiciel qui utilise GCC".
"La première sécurité est la liberté"
[^] # Re: IR
Posté par TImaniac (site web personnel) . Évalué à 1.
Et ? Qui te dit qu'il n'a pas réalisé un outil qui "utilise" les 2 ? D'où l'incompatibilité ?
[^] # Re: IR
Posté par LeMagicien Garcimore . Évalué à 7.
C'est super de partir du principe que les gens sont des idiots sans vraiment savoir ce qu'ils ont fait. Tu peux pas supposer qu'il sait de quoi il parle ?
Si ma mémoire est bonne (j'ai lu ses articles il y a longtemps), ce qu'a fait Matthieu Moy c'est un analyseur de design SystemC, en utilisant le frontend de GCC pour extraire la structure et le comportement du design.
[^] # Re: IR
Posté par Matthieu Moy (site web personnel) . Évalué à 5.
Roh, ça fait plaisir, des gens qui ont entendu parler de Pinapa ;-). Bon, je voulais éviter de transformer mon message en auto-publicité, mais trop tard.
Oui, Pinapa utilise GCC (le compilo, pas libgcc) et SystemC dans le même exécutable. Et non, c'est pas un hasard si le successeur de Pinapa utilise LLVM ... Nicolas, si tu as toujours du mal à me croire, je t'invite à aller vérifier dans les sources.
[^] # Re: IR
Posté par houra . Évalué à 1.
Et c'est quelle partie de la license de SystemC qui interdit l'usage du binaire généré à partir d'un logiciel GPLv3 ?
Sedullus dux et princeps Lemovicum occiditur
[^] # Re: IR
Posté par Nicolas Boulay (site web personnel) . Évalué à 4.
SystemC avait aux derniers nouvelles une licence non compatible avec la GPL à cause d'une clause défensive anti-brevet.
"La première sécurité est la liberté"
[^] # Re: IR
Posté par rewind (Mastodon) . Évalué à 5.
Comme l'ont déjà dit d'autres, la spécificité de LLVM est que cette représentation intermédiaire est bien spécifié (il suffit de cliquer sur le lien). Et c'est même plus que ça, c'est un langage assembleur à part entière qui peut être utilisé tel quel. Est-ce qu'on a la même chose pour GCC ? Non (et c'est bien dommage à mon sens). Et même, je dirais qu'aucune machine virtuelle que je connaisse ne permet de coder directement en "assembleur" aussi facilement.
Quand au troll sur la licence, on ne peut contester que LLVM est utilisé en partie à cause de ça. Maintenant, est-ce que ça change quoi que ce soit au reste, c'est-à-dire aux vrais arguments techniques ? Non, absolument pas. En tout cas, pour ma part, je m'y intéresse pour ses qualités techniques, et pas à cause de sa licence. Je suis un libriste tendance RMS, et ça ne me dérangerait absolument pas que LLVM soit GPL. Ce n'est pas le cas, ce n'est pas grave, c'est compatible GPL quand même.
[^] # Re: IR
Posté par neologix . Évalué à 5.
Au moins cPython :
http://wiki.python.org/moin/ASTBasedOptimization
# Phoronix
Posté par JGO . Évalué à 7.
À la sortie de LLVM 2.8 (octobre) Phoronix avait fait des tests.
Les résultats étaient, en résumé :
http://www.phoronix.com/scan.php?page=article&item=llvm_gcc_dragonegg28&num=1
[^] # Re: Phoronix
Posté par Maclag . Évalué à 10.
Mouai.
Pour une bonne comparaison, il faudrait compiler LLVM avec GCC et GCC avec LLVM, ensuite on recommence le bench, et on conclut que c'est un peu le bordel dans les données.
Ce qui tombe bien, parce qu'on est vendredi, et que finalement les données qui ne veulent rien dire, c'est bon pour les Trolls!
-----------> [ ]
[^] # Re: Phoronix
Posté par djabal . Évalué à 6.
Sinon on peut prendre le test Phoronix GCC 4.6, LLVM/Clang 2.9, DragonEgg Five-System Benchmarks, publié il y a peine deux semaines.
Toujours les même tendances générales cela dit : gcc produit des binaires plus rapides et LLVM compile plus rapidement.
[^] # Re: Phoronix
Posté par M . Évalué à 4.
Mouais le bench est pas super : il n'indique pas comment les binaires ont été compilé.
On peut apprendre [1] que certains bench se font on -O0 ou que certain exploite openmp (non supporter par clang)...
[1] http://thread.gmane.org/gmane.comp.compilers.clang.devel/14059/focus=14084
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.