LLVM 2.8, ça avance !

Posté par  (Mastodon) . Modéré par patrick_g.
Étiquettes :
31
22
oct.
2010
Technologie
Une nouvelle version de LLVM (Low-Level Virtual Machine) est sortie le 5 octobre 2010. Elle se nomme LLVM 2.8 et suit la version 2.7 sortie le 27 avril dernier. LLVM est une infrastructure de compilation sous licence BSD et est soutenue par Apple. Elle représente en fait une boîte à outils pour réaliser des compilateurs, des machines virtuelles et plein d'autres choses. Elle est fondée sur un langage assembleur typé qui sert de représentation intermédiaire pendant la compilation, mais également de bytecode sur le disque et de langage assembleur à part entière. Le projet LLVM développe également nombre de sous-projets, et non des moindres, comme Clang qui est un compilateur C/C++/Objective C/Objective C++.

Cette nouvelle version apporte plein d'améliorations, notamment au niveau des performances, et de nouveautés, que ce soit dans LLVM ou dans les projets annexes. Quelques-unes des principales avancées sont données dans la suite de la dépêche. Clang
Clang a maintenant atteint une certaine maturité et est considéré comme utilisable en production pour tous les langages C, C++, Objective C, Objective C++. Cette version 2.8 apporte une compatibilité avec les standard C++ 1998 et 2003, ainsi qu'Objective C++, la gestion de certains #pragma de GCC (visibility et align), la gestion d'instructions étendues (SSE, AVX, ARM NEON, et AltiVec), la gestion des en-têtes C++ précompilés. Clang utilise maintenant l'architecture MC (Machine Code, voir après) pour générer du code binaire et analyser syntaxiquement l'assembleur inline.

Machine Code
Le sous-système MC est la partie chargée de gérer tous les problèmes au niveau assembleur et code objet. Il s'agit encore une fois d'une collection de petits modules qui ont un rôle particulier mais qui, une fois conjugués, permettent de fabriquer des assembleurs, des désassembleurs, et d'autres outils qui travaillent à ce niveau.

La version 2.8 permet enfin de générer du code objet pour l'architecture darwin/x86[-64] et est donc utilisée par llc (qui transforme le bytecode en code objet) et Clang (auparavant, Clang générait un fichier assembleur texte qui était compilé par un assembleur externe). Le développement est en bonne voie pour la prise en charge du jeu d'instructions ARM et pour les format objet ELF et COFF. Comme dit précédemment, MC est aussi utilisé pour compiler l'assembleur inline. Une des forces de l'intégration de MC et Clang au sein de LLVM est qu'il est possible de remonter les erreurs au niveau de l'assembleur inline directement dans CLang, chose impossible à faire avec GCC qui appellent un processus externe (as) et donc perd les informations sur le code source original en C.

libc++
libc++ est une implémentation de la bibliothèque standard C++ telle que définie dans le futur standard C++0x. Cette nouvelle implémentation a été décidée sur trois critères : créer une bibliothèque standard performante en utilisant toute l'expérience accumulée par les autres implémentations sans s'occuper de la compatibilité binaire avec l'existant, avoir une bibliothèque standard non-GPL, ne pas s'occuper de la compatibilité avec les anciens standard C++ mais directement viser C++0x.

Cette bibliothèque, bien que très jeune, est déjà quasiment complète. Il lui manque juste le compilateur qui va avec, donc la gestion du C++0x dans Clang.

LLDB, Low Level Debugger
LLDB est le dernier né des sous-projets de LLVM. C'est un nouveau débogueur qui en est encore à ses débuts mais qui est construit comme le reste des sous-projets de manière modulaire et qui réutilise des modules venant d'autres sous-projets, comme le désassembleur LLVM, ou l'analyseur syntaxique de Clang.

Les autres sous-projets
Le sous-projet compiler-rt permet à présent de disposer des morceaux de code bas-niveau nécessaires pour la compilation, comme certaines conversions de types de base, ou une implémentation d'une unité de calcul flottant logicielle pour les architectures qui ne disposent pas d'une unité matérielle.

DragonEgg, le greffon GCC qui permet de remplacer l'optimisation et la génération de code de GCC par celles de LLVM poursuit son chemin et est maintenant capable de compiler de l'Ada, du Fortran, du C et du C++. Entre autres améliorations, notons un temps de chargement plus court grâce à une réduction du nombre de symboles exportés.

Le sous-projet VMKit est un ensemble de modules pour fabriquer des machines virtuelles. À l'origine, le but était d'avoir une implémentation de la JVM et une implémentation de la machine virtuelle de .NET. Malheureusement, le développement de cette dernière a été abandonné.

Projets utilisant LLVM
La liste des projets utilisant LLVM s'allonge encore. On peut notamment citer plusieurs nouveaux langages de programmation :
  • Horizon est un langage de bytecode qui vise les systèmes d'exploitation à espace d'adressage unique ;
  • Clay est un langage de programmation système utilisant la programmation générique ;
  • Crack est un langage de script qui s'inspire de C, C++, Java et Python et dont le but est de s'exécuter aussi vite qu'un langage compilé. Il est réalisé par Google et les notes donnent une assez bonne idée de ce à quoi veut ressembler ce langage ;
  • Kai (会) est un interpréteur expérimental utilisant des expressions symboliques imbriquées.
ClamAV, le célèbre antivirus libre, utilise également LLVM. Il a amélioré son interpréteur de bytecode interne en utilisant le compilateur JIT de LLVM, ce qui lui permet au passage d'écrire des tests de virus en C.

Aller plus loin

  • # Merci Apple

    Posté par  (site web personnel) . Évalué à -6.

    Profitons-en pour rendre hommage à Apple et Steve Jobs de nous apporter ce formidable compilateur open source qui servira de brique de base pour construire les app-store de demain !

    • [^] # Re: Merci Apple

      Posté par  (site web personnel) . Évalué à -9.

      Rendons également hommage à IBM pour leurs magnifiques contributions au libre réalisée grâce à l'argent des nazis [1].

      [1] http://www.ibmandtheholocaust.com/

      (j'ai gagné un point :) )

    • [^] # Re: Merci Apple

      Posté par  . Évalué à 10.

      RAPPELONS AUSSI QU'ILS NE SONT PAS À L'ORIGINE DU COMPILATEUR ET QUE C'EST LE SEUL SUR LEQUEL ILS POUVAIENT SE RABATTRE QUI N'ÉTAIT PAS SOUS GPL3.

      « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

      • [^] # Re: Merci Apple

        Posté par  . Évalué à 7.

        COMME QUOI, LA LICENCE BSD A ÉTÉ UN CHOIX JUDICIEUX POUR LES CRÉATEURS DE LLVM.

        Envoyé depuis mon lapin.

        • [^] # Re: Merci Apple

          Posté par  (site web personnel) . Évalué à 1.

          JUDICIEUX POUR QUI ?

          SINON LE CAPS LOCK DAY C'ÉTAIT VENDREDI DERNIER

          • [^] # Re: Merci Apple

            Posté par  . Évalué à 3.

            Pour les créateurs de LLVM ? C'est une question piège ?

            Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

            • [^] # Re: Merci Apple

              Posté par  (site web personnel) . Évalué à -3.

              J'ai plutôt l'impression que c'était judicieux pour Apple. Comme ça ils peuvent distribuer du binaire basé sur du logiciel open source en gardant les patchs pour eux. Je ne vois vraiment pas ce que LLVM a à y gagner.

    • [^] # Re: Merci Apple

      Posté par  . Évalué à 2.

      Profitons-en pour rendre hommage à Apple et Steve Jobs de nous apporter ce formidable compilateur open source qui servira de brique de base pour construire les app-store les prisons électroniques de demain !

      PS: AppStore arrive bientôt sous OSX, AppStore : Synaptic sous DRM,
      bon courage les macqueux les macqués.

    • [^] # Re: Merci Apple

      Posté par  (Mastodon) . Évalué à 10.

      Confondre l'outil et son utilisation potentiellement malveillante, c'est digne de l'HADOPI qui confond P2P et contrefaçon...

    • [^] # Re: Merci Apple

      Posté par  . Évalué à 3.

      compilateur qui est malheureusement axé pas mal apple :
      - la target principal est darwin x86 et arm. Le support des autres os tient parfois du hack ou n'est pas correct (au niveau ABI). Le support des autres archi (sparc, ppc) est pauvre.
      - support de la cross compilation marche bien que sous MacOS
      - le support de arm est orienté sur les coeurs récent (utilisé dans les iphone). Pour les plus vieux armv5, il existe des bugs qui n'interresse pas les développeurs.

      De plus il se fait passer pour gcc, mais ne l'émule pas toujours correctement.

      Ca avance, mais il n'a pas l'air d'être encore bon pour faire des trucs industriel sous Linux.

      • [^] # Re: Merci Apple

        Posté par  (site web personnel) . Évalué à 5.

        Personnellement, je l'utilise tous les jours sous Linux x86-64 et je n'ai pas eu tant de problème que ça. clang++ compile globalement plus vite que g++ (même 4.5.1), et il affiche des messages d'erreurs compréhensibles. Le code généré est toutefois un peu moins bon que celui fourni par g++.

        Alors oui, on peut râler, apple patati patata, mais bon le code est sous licence BSD, et n'importe qui peut l'améliorer. En attendant, llvm fournit une bonne base pour faire des analyseurs statiques, des IDE, des expérimentations de nouveaux langages, là ou gcc et son architecture ultra monolithique emmerde le monde. SI il y'a des bugs, on peut les corriger, non, le code est libre (et y'a des bugs dans gcc aussi heing sur les architectures exotiques :)).

        Enfin, on peut se plaindre du support processeur de llvm mais gcc a aussi supprimé le support d'un tas d'architectures matériels (voir tous les ports où NetBSD utilisant encore un gcc3). Dans le même temps, llvm fonctionne assez bien sur FreeBSD pour avoir été integré au base système.

        • [^] # Re: Merci Apple

          Posté par  . Évalué à 2.

          llvm fonctionne assez bien sur FreeBSD pour avoir été integré au base système.

          Encore une raison pour tenter le couple Linux+Userland BSD! au lieu de faire l'inverse GNU/KFreebsd

          cf: mon précédent message sur :
          https://linuxfr.org/comments/1173322.html#1173322

          Franchement les gars, ça n'existe pas? Ou dis-je une connerie énorme quant au concept?

      • [^] # Re: Merci Apple

        Posté par  . Évalué à 8.

        compilateur qui est malheureusement axé pas mal apple :

        En tout cas ça ne me choque pas :
        - les sources sont dispo
        - il semble modulaire

        deces 2 faits, n'importe qui ayant besoin d'un compilo pour supporter son archi peut reprendre l'ensemble du code et adapter la partie qui l'intéresse.

        Qu'Apple s'oriene surtout vers les architectures qu'il supporte, c'eszt normal, tant qu'ils n'empêchent pas les autres par une politique torue, d'utiliser le code source pour faire ce qu'ils veulent.

        Autant je n'aime pas Apple sur certains points, autant là dessus il n'y a rien à leur reprocher (c'est un peu comme la majorité des devs de logiciel libre qui ne codent que pour Linux et qui se moquent totalement de la portabilité, et il y en a des tas).

        • [^] # Re: Merci Apple

          Posté par  . Évalué à 9.

          deces 2 faits

          Sincère condoléances.

          « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

  • # Scala

    Posté par  . Évalué à 4.

    Et à noter un travail de compilation de Scala vers LLVM :
    http://github.com/greedy/scala

    \o/

  • # ca sent le roussi pour .Net

    Posté par  . Évalué à 3.

    une implémentation de la machine virtuelle de .NET. Malheureusement, le développement de cette dernière a été abandonnée.

    Entre ca et l'abandon de ironpython c'est tout de meme curieux je trouve, non pas que cela me deplaise.

    • [^] # Re: ca sent le roussi pour .Net

      Posté par  . Évalué à -2.

      EUH OUAIS ENFIN L'IMPLÉMENTATION DE LA MACHINE VIRTUELLE .NET VIA LLVM/VMKIT ÉTAIT À CE QUE JE SAIS RÉALISÉE PAR UN UNIQUE DOCTORANT PENDANT SA THÈSE ET À L'UTILISATION , JE NE PENSE PAS QUE SON ABANDON REPRÉSENTE QUELQUE-CHOSE À L'ÉCHELLE DE L'ÉCOSYSTÈME.

  • # Qt Creator

    Posté par  (site web personnel) . Évalué à 2.

    A noter que les développeurs de Qt Creator (l'IDE de Nokia pour développer en Qt) suivent le développement de CLang et LLDB et sont a priori assez intéressés par le bousin. On peut donc espérer une intégration dans Qt Creator, certainement une fois que LLDB sera utilisable.

    source : http://labs.qt.nokia.com/2010/10/15/peek-and-poke-vol-4/

    • [^] # Re: Qt Creator

      Posté par  . Évalué à 1.

      CE QUI SERAIT BIEN, C'EST D'AVOIR LE CHOIX (MAIS ÇA FAIT BEAUCOUP DE TRAVAIL EN PLUS POUR PAS GRAND CHOSE).

      « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

      • [^] # Re: Qt Creator

        Posté par  (site web personnel) . Évalué à 2.

        A priori il y aura le choix puisqu'actuellement tu as le choix sous windows entre gcc/gdb ou msvc/cdb. Du coup toute l'infrastructure pour gérer différent compilateur/débuggeur est en place.

        D'ailleurs, il serait étonnant qu'ils abandonnent gcc/gdb vu le nombre d'utilisateur de ces outils.

      • [^] # Re: Qt Creator

        Posté par  . Évalué à 1.

        C'est quoi cette nouvelle manière d'écrire en majuscule ? Vous êtes EN COLÈRE ou c'est une question de clavier BLOQ

        • [^] # Re: Qt Creator

          Posté par  (Mastodon) . Évalué à 2.

          C'est le caps-lock day. Et vivement que ça se termine.

          • [^] # Re: Qt Creator

            Posté par  . Évalué à 1.

            AUTANT POUR MOI...

            • [^] # Re: Qt Creator

              Posté par  . Évalué à 1.

              TIENS, SI TU VEUX TE RENSEIGNER: HTTP://CAPSLOCKDAY.COM

              « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

            • [^] # Re: Qt Creator

              Posté par  . Évalué à 4.

              AU TEMPS POUR TOI, tu voulais dire ?

              (ben quoi ? le troll-day c’est tout les vendredi !)

  • # Pour moi clang est plus lent que gcc 4.5.1à compiler et ça bug

    Posté par  . Évalué à 1.

    Bonjour,
    j'ai fait quelques tests avec clang et il est à chaque fois plus lent de peu pour compiler. Je n'ai fait des tests sur que des exemples de programmes avec Qt. Et sur l'exemple wolfenqt, en plus le programme une fois compilé plante avec un "segmentation fault" alors qu'il fontionne très bien compilé avec ggc.
    Je n'ai pas regardé d'ou venait l'erreur mais bon. Je suis de toute façon intrigué par le fait qu'ils indiquent que c'est bien plus rapide que gcc.
    Si quelqu'un a une idée du pourquoi de la chose. Merci
    Bonne journée

  • # clang est déjà dans ma distribution

    Posté par  . Évalué à 1.

    Je ne sais pas comment il a été compilé, je suppose en mode releave logiquement (paquet archlinux). Par contre pour le moment il faudrait aussi que les "fichiers d'entêtes" passent avec clang. Avec gcc ça "explose" les temps de compilation (divison par 4 sur des petits projets), mais j'ai une erreur "unable to read PCH file: 'Is a directory'" si je passe sur clang donc faudra déjà que je règle cela.
    Bon si le fait que Qt ait été compilé sur archlinux avec gcc fait que ça plante, ça va pas être évident non plus. Car si je dois recompiler toutes les bibliothèques avec clang c'est pas gagné. Je suis pas expert en compilation mais je croyais qu'il y avait un format standard pour les binaires ?
    Bonne soirée

  • # Relecture et correction

    Posté par  . Évalué à 1.

    J'ai relevé les fautes suivantes :

    - « boite », boîte, la boite ou boëte, c'est de la vinasse ;
    - « Cette nouvelle implémentation a été décidé », décidée ;
    - « LLDB est le dernier né des sous-projet », sous-projets ;
    - « débuggueur », (franglais) soit débogueur (français), soit debugger (anglais);
    - « implémentation d'une unité de calcul flottant logiciel », logicielle ;
    - « les architectures qui ne dispose pas d'une unité matérielle », disposent ;
    - « Malheureusement, le développement de cette dernière a été abandonnée. », abandonné.

    Ça fait beaucoup quand même...

  • # Rubunius

    Posté par  . Évalué à 1.

    À noter le projet Rubinius qui utilise LLVM.

    http://rubini.us/

Suivre le flux des commentaires

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