La version 2.5 du compilateur LLVM est disponible

Posté par (page perso) . Modéré par patrick_g.
Tags :
18
4
mar.
2009
Technologie
Le compilateur LLVM (pour Low Level Virtual Machine) est disponible dans sa version 2.5 depuis le 2 mars dernier.
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.
Du côté du projet Clang qui est destiné à remplacer GCC dans les futures versions, il y a aussi du nouveau. Clang est capable d'analyser du code source écrit en C et en Objective-C (ce dernier étant très important pour Apple puisqu'il est à la base de la plupart des logiciels écrits par la firme de Cupertino) mais il ne peut toujours pas accepter le C++ du fait de la redoutable complexité de ce langage. Le travail continue donc pour parvenir à analyser correctement les sources en C++ même si le chemin est encore long.
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 !
  • # Virtual Machine && Gallium3D

    Posté par . Évalué à 8.

    LLVM permet aussi l'utilisation d'une machine virtuelle. Il y a même été discuté d'utiliser LLVM pour distribuer des plasmoids cross plate-forme.

    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 . Évalué à 8.

      > Je ne sais pas si Apple utilise LLVM pour OpenCL.
      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 . Évalué à 4.

      Gallium3D utilise LLVM pour compiler les shaders, pour les cartes disposant d'unités programmables.
      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 (page perso) . Évalué à 10.

    En définitive le projet LLVM semble avoir le vent en poupe et GCC donne le sentiment de bouger moins vite que lui...

    C'est plus facile de "bouger" quand il manque énormément de fonctionnalités à implémenter.
    • [^] # Re: Oui mais...

      Posté par . Évalué à 8.

      C'est plus facile de bouger quand on pas pas 20 ans de code obsolète derrière. GCC est en bonne voie de se débarasser des vieilleries mais ils ont pas mal d'effort à faire encore.
      • [^] # Re: Oui mais...

        Posté par . Évalué à 5.

        J'avais lu un blog sur WebKit et Gecko. Ça disait que WebKit est plus "propre". Mais que depuis quelques temps il y avait plein de hack "à l'arrache" pour paufiner les détails, pour répondre aux besoins spécifques de Safari, etc. Bref, WebKit comme LLVM devra faire avec du "code obsolète derrière" ou des hacks pas très propres.
        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 . Évalué à 3.

          > Combien de temps il faudra encore pour avoir un compilateur C++ correcte ?
          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 . Évalué à 4.

            Je n'ai pratiquement rien contre LLVM. Quoique je préfère la GPL.
            LLVM investit des voies qui va donner des idées à gcc, comme gcc a donné des idées à LLVM.
            • [^] # Re: Oui mais...

              Posté par . Évalué à 2.

              D'ailleurs il existe des devs qui bossent à la fois dans gcc et dans llvm :)
          • [^] # Re: Oui mais...

            Posté par . Évalué à -2.

            Donc en fait LLVM fait parfois presque aussi bien que GCC...quand il utilise GCC !!!
            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 (page perso) . Évalué à 4.

              >>> 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 ??

              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 . Évalué à -3.

                Non seulement tu tentes de faire un lavage de cerveau sur LLVM à la communauté du libre francophone, mais en plus tu le cache en rédigeant aussi les news GCC....C'est plutôt pire non ???
    • [^] # Re: Oui mais...

      Posté par . Évalué à 4.

      Repartir sur une architecture propre qui supporte les dernières avancées de la compilations sans nécessiter de lourdes évolutions dans du code existant, ça a ses avantages aussi ...
    • [^] # Re: Oui mais...

      Posté par . Évalué à 2.

      C'est en partie lié a ça, mais je me demande si ce ne sont pas des raisons de politiques qui expliquent que LDC soit en pleine forme mais que GDC n'ai pas décollé: le refus d'intégrer GDC dans GCC a pu refroidir les contributeurs..

      J'ignore la raison, mais la difference entre les deux est frappantes!
  • # et pendant ce temps...

    Posté par (page perso) . Évalué à 5.

    une dépêche sur gcc 4.4 se morfond en modération depuis le 18 décembre (mieux vaut préciser l'année si ça continue : 2008), plombant nos stats de réactivité...

    "release early, release often" qu'ils disaient /o\
  • # Et les perfs ?

    Posté par . Évalué à 1.

    Quelqu'un a-t-il des infos là-dessus ?

    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 (page perso) . Évalué à 3.

      >>> "Il paraît" que gcc est un peu mou du genou sur ce point.

      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 . Évalué à 2.

        "cf la news de GCC 4.4 à venir)"
        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 (page perso) . Évalué à 5.

          Ben au moment de partir en vacances de Noël j'ai eu peur que GCC 4.4 ne sorte sans que je ne puisse poster la news alors je l'ai envoyé par anticipation.
          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 . Évalué à 2.

            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 !

            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 (page perso) . Évalué à 2.

            Je pensais que la version 4.4 allait sortir rapidement...mais j'ai été trop optimiste

            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 . Évalué à 1.

        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.


        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 . Évalué à 7.

    Je suis pas mal les évolutions de GCC ainsi que de LLVM et je dois dire que ce dernier progresse rapidement malgré sa jeunesse, grace a clang on peut meme recompiler un noyau BSD ou linux par exemple.
    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 (page perso) . Évalué à 6.

      s'il pouvait me contacter j'aurais quelques questions.

      comme cela se dit souvent sur irc, "don't ask to ask, just ask" ;-)

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.