LLVM 2.4 : le compilateur qui fait plus

Posté par  . Modéré par baud123.
Étiquettes :
24
12
nov.
2008
Technologie
La version 2.4 de la suite LLVM est sortie le 9 novembre.

LLVM est l'acronyme de Low Level Virtual Machine, mais c'est aussi :
  • un compilateur, avec des interfaces pour C, C++ au travers du projet CLang et du port des analyseurs de code C, C++ de GCC. D'autres langages sont également pris en charge.
  • un framework de compilateur qui permet d'ajouter simplement des nouveaux langages ou des nouvelles architectures matérielles.
  • un générateur de code embarquable pour la compilation à la volée (JIT).
  • une stratégie de compilation conçue pour autoriser des optimisations pendant toute la durée de vie d'un programme, c'est à dire à la compilation, pendant l'édition de lien, pendant l'exécution, et par profilage après l'exécution.
  • un jeu d'instruction virtuel, la représentation intermédiaire (IR). Celle-ci est accessible sous forme textuelle (c'est l'assembleur LLVM) ou binaire (c'est le bytecode LLVM). C'est cette représentation intermédiaire qui permet les optimisations.
La version 2.4 de LLVM apporte son lot de corrections de bogues, des temps de compilations réduits en utilisant -O0, des améliorations sur la génération de code, une nouvelle architecture cible (PIC16), de nouvelles possibilités pour la représentation intermédiaire, et de nombreuses autres améliorations et ajouts.

LLVM est le seul concurrent sérieux et libre de GCC GNU Compiler Collection. Il se distingue par sa conception très modulaire et sa simplicité d'utilisation. Cela se reflète dans son API et sa documentation abondante. Il existe même un tutoriel décrivant l'implémentation d'un petit langage en utilisant LLVM !
Évidemment, LLVM propose beaucoup moins de langages et d'architectures que GCC, mais il rattrape son retard et est déjà une alternative tout à fait valable à GCC en utilisant LLVM-GCC.

On peut essayer LLVM sans trop d'effort en le téléchargeant avec l'interface llvm-gcc. Vous pourrez ainsi compiler vos programmes favoris en utilisant la commande llvm-gcc de la même façon que vous utilisez gcc.

Il convient également de citer 2 projets annexes à LLVM, et qui évoluent avec celui-ci :
  • CLang est un projet dont le but est de fournir des interfaces C, C++ et Objective C pour LLVM qui soient de meilleure qualité que ce qui existe actuellement (les parseurs de GCC).
  • VMKit est une implémentation de la JVM et de la CLI. Il transforme le bytecode java et MSIL en représentation intermédiaire LLVM puis effectue les optimisations fournies par LLVM.
Enfin, signalons que des vidéos et présentations de la rencontre annuelle des développeurs de LLVM du 2 août 2008 sont disponibles.

Aller plus loin

  • # ref

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

    Lien wikipedia CLI pas bon, le bon lien :
    http://fr.wikipedia.org/wiki/Common_Language_Infrastructure

  • # The CC Wars

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

    J'aime bien le "LLVM est le seul concurrent sérieux et libre de GCC" alors deux jours auparavant, un article concernant PCC déclarait "Beaucoup voient en lui une alternative viable à GCC qu'il pourra à terme remplacer." On dirait comme une revanche de cet article sur le précédent.

    Personnellement, je n'utilise que GCC. En lisant l'article sur PCC (http://linuxfr.org/2008/11/10/24664.html), je n'ai même pas bien compris en quoi il pouvait rivaliser avec le compilateur GNU (exécution plus lente, moins d'architecture, moins d'optimisation...).

    LLVM me parait déjà plus intéressant. Le modulaire, souvent, c'est bien et j'ai bien envie de gouter cette compilation à la volée pour C.

    Sans aller jusqu'à chercher forcément à détrôner le "Grand Compilateur C", je trouve intéressant qu'il existe d'autres projets viables. C'est l'un des avantages du Libre : avoir le choix. Je ne pense pas remplacer mon gcc mais pourquoi pas tester LLVM par exemple.

    Existe-t-il des comparatifs ou bench de ces compilo ?

    • [^] # Re: The CC Wars

      Posté par  . Évalué à 5.

      LLVM est si je ne m'abuse déjà utilisé dans la compilation de "shaders" pour les cartes graphiques 3D, par le projet Gallium3D.
      Je ne connais pas d'utilisation de GCC dans ce contexte.
      Bref ça ouvre d'autres possibilités qui n'ont pas encore été prises en compte par le projet GCC, est c'est trés intéressant.

    • [^] # Re: The CC Wars

      Posté par  . Évalué à 4.

      Comme signalé dans l'article, lorsqu'on est habitué à GCC, le plus simple est d'essayer llvm-gcc. Ainsi on a le même fonctionnement qu'avec GCC en profitant des optimisations de LLVM.

      Pour ce qui est des benchmarks, il y a ça mais c'est assez vieux:
      http://lucille.atso-net.jp/blog/?p=430

      • [^] # Re: The CC Wars

        Posté par  . Évalué à 2.

        C'est pas très complet, il faudrait avoir un run de SPEC (en général c'est facile de sortir un unique benchmark sur lequel ton compilo s'en sort bien, sur l'ensemble d'une suite de bench c'est déjà plus dur).

        • [^] # Re: The CC Wars

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

          Ici une comparaison qui a l'air assez sérieuse : http://vmakarov.fedorapeople.org/spec/llvmgcc.html

          • [^] # Re: The CC Wars

            Posté par  . Évalué à 3.

            Pour info, pour les scores de SPEC2k, plus haut c'est mieux (ie, gcc gagne).

            • [^] # Re: The CC Wars

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

              Oui mais LLVM compile plus vite et les scores de performances qu'il obtient ne sont pas loin de GCC (sauf sur le test 176.gcc ou il se crashe ce qui oblige à compiler en -O0).
              Moi je dis pas mal du tout.

              • [^] # Re: The CC Wars

                Posté par  . Évalué à 4.

                J'ai pas dit que c'était mal :)

                C'était juste les infos pour pouvoir interpréter les graphes. Mais 5% c'est quand même beaucoup dans le monde des compilos. Sinon pour les temps de compil, la différence doit être encore plus élevé avec le frontend clang (qui est notamment fait pour pouvoir faire de l'analyse semantique à la volée pour montrer les erreurs dans un IDE, il est donc très rapide).

                • [^] # Re: The CC Wars

                  Posté par  . Évalué à 3.

                  Pour les compilos peut-être, mais en final ce sont les utilisateur qui choisissent: j'ai bossé sur des projets qui mettaient 3 heures à compiler (vive le C++) et si j'avais eu la possibilité d'avoir 30% de temps de compilations en moins pour 5% de perte de perf, j'aurais signé sans problème!

                  • [^] # Re: The CC Wars

                    Posté par  . Évalué à 2.

                    Il faut dire que pour moi les utilisateurs c'est dans l'embarqué et là ils sont prêt à tout pour gagner 5% même si ça prend des heures (vu les gains en espace mémoire et en autonomie de batterie).

                    • [^] # Re: The CC Wars

                      Posté par  . Évalué à 4.

                      Pourquoi ne pas utiliser au mieux les forces de ces compilateurs?

                      A priori, si ton projet le supporte, tu pourrais utiliser LLVM pour développer (cycle code / compile / éxécution rapide), et utiliser GCC pour générer les binaires pour les équipes de test et pour générer l'exécutable final?

                      • [^] # Re: The CC Wars

                        Posté par  . Évalué à 2.

                        En pratique ils jouent surtout sur les options de compil pour diminuer le temps de compil. Et sinon c'est un compilo basé sur Open64 (je pense pas que l'archi soit porté sur gcc ou sur llvm).

      • [^] # Re: The CC Wars

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

        Il y a un détail qui potentiellement casse tout : sous Mac l'option -fno-strict-aliasing n'est pas activée par défaut en -O3 alors qu'elle l'est sous Linux.
        Cette option a de grosse implication niveau perf, mais si elle impose de faire attention à ce que l'on met dans son code.
        Si LLVM l'implémente de son côté, dans sa partie à lui, faut pas s'étonner de tels différences de perfs.
        Mettre 35% à GCC 4.2, sur un exemple précis, en utilisant les capacités spécifiques du Core Duo, ok, mais en général, j'y crois peu.

        Bref, il faudrait faire le test sous linux...

        « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

    • [^] # Re: The CC Wars

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

      > un article concernant PCC déclarait "Beaucoup voient en lui une alternative viable à GCC qu'il pourra à terme remplacer."

      C'est surtout que PCC est limité au C alors que LLVM et GCC ont une architecture beaucoup plus modulaire et ont pour but de compiler beaucoup plus de langages.

      Il existe par exemple SmalltalkKit permettant d'utiliser le JIT de LLVM pour en faire un langage dynamique compatible avec Objective-C (enfin si j'ai bien tout compris ;))

      PCC de ce côté là n'est pas du tout un concurrent de LLVM, mais il peut l'être (comme de GCC) sur la partie C.

      • [^] # Re: The CC Wars

        Posté par  . Évalué à 3.

        C'est surtout que PCC est limité au C alors que LLVM et GCC ont une architecture beaucoup plus modulaire et ont pour but de compiler beaucoup plus de langages.

        C'est faux. PCC est très modulaire, ce qui lui permet de supporter "facilement" de nouveaux langages et de nouvelles architectures. D'ailleurs PCC est capable de compiler du fortran 77.

        • [^] # Re: The CC Wars

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

          ok, je ne savais pas.
          Mais pourtant le site de PCC [http://pcc.ludd.ltu.se/] indique que le but est de créer un compilateur C99
          Donc la question suivante, à part fortran 77 (qui est fourni avec PCC, donc un peu une proof of concept) il existe d'autres langages supportés ou c'est juste pour montrer que c'est possible ?

          • [^] # Re: The CC Wars

            Posté par  . Évalué à 4.

            "Proof of concept" est probablement l'expression appropriée pour l'implémentation de fortran 77 dans PCC. Il n'y a pas d'autre langages supportés car personne n'en a suffisamment besoin pour mettre les mains dans le cambouis... ce qui n'est pas le cas pour le C99

            Au niveau de la modularité, si on veut porter PCC vers une nouvelle architecture, on peut le faire en environ 5 000 lignes de codes. Chaque tâche de la compilation a bien été séparée de sorte que l'on puisse facilement échanger le backend (la partie qui produit le code machine) et le frontend (la partie qui analyse et traite la syntaxe du langage). Enfin bon ce disgn n'est pas nouveau puisqu'il date d'il y a 30 ans, pour en savoir plus : la présentation de l'architecture de PCC au NYCBSDCon 2008 : http://www.nycbsdcon.org/2008/files/magnusson_pcc.pdf

            Bien évidement ce petit compilateur n'a pas du tout pour but de concurrencer LLVM car il ne répond pas au même besoin.

        • [^] # Re: The CC Wars

          Posté par  . Évalué à 5.

          D'ailleurs PCC est capable de compiler du fortran 77.

          Sachant qu'il y a 3 generations de fortran derriere cela laisse reveur avec des changement fondamentaux surtout par rapport au 77 qui est vraiment mais vraiment obsolete. Programmation a la grand pere on va dire gentiment.

          GCC supporte quand a lui les normes 90 et son evolution 95, la norme 2003 commence a etre bien supporte, elle aussi un changement majeur qui apporte la compatibilite C et la programmation objet, et un debut d'implementation des nouveautes de la futur norme 2008.

          http://gcc.gnu.org/wiki/GFortran

          • [^] # Re: The CC Wars

            Posté par  . Évalué à 1.

            Sachant qu'il y a 3 generations de fortran derriere cela laisse reveur avec des changement fondamentaux surtout par rapport au 77 qui est vraiment mais vraiment obsolete.

            Euh. Obsolète ? J'irai le dire à certains gros industriels qui produisent encore aujourd'hui du code F77 pour de très grosses applis (genre simulation de procédés de fonderie).

            Cela dit, oui, implémenter FORTRAN 77 est bien plus simple que ses successeurs.

            • [^] # Re: The CC Wars

              Posté par  . Évalué à 6.

              C'est pas parce que c'est utilisé que c'est pas obsolète, y'a encore des gens qui se déplacent en calèche par exemple.

              • [^] # Re: The CC Wars

                Posté par  . Évalué à 6.

                Calèches bien souvent conçues grâce à des simulateurs écrits en fortran77, d'ailleurs.

            • [^] # Re: The CC Wars

              Posté par  . Évalué à 3.

              Comme dit en dessous c'est pas parceque c'est utilise que c'est pas obsolete de plus la norme 90 indique bien qu'un programme 77 doit conpiler dessus et donc, si la norme a ete respecte mais vu que l'on parle de portabilite compilateur le probleme est quasiment le meme, le programme compilera avec un compilateur 90. L'avantage c'est que cela permet de moderniser au fur et a mesure le programme.

              Mais pour en revenir a ton point je le sais pertinnement et le pire c'est que tu retrouves probablement des partie en fortran 66 (ie fortran 4) et c'est ca qui empeche probablement le passage a un compilo 90 sans compter que debugger des common c'est le bohneur integral...

    • [^] # Re: The CC Wars

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

      LLVM est le seul concurrent sérieux au Gnu Collection Compiler, le Portable C Compiler n'étant, pour l'instant, qu'un compilateur C.

    • [^] # Re: The CC Wars

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

      Plp Gedsismik

      CompBench est un benchmarker de compilation (pas exactement de compilateurs) selon des scénarios. Mais il intègre déjà TCC en plus de GCC (et il est peut être question de voir la branche MELT de GCC ?). En tout cas, il est probable que si des utilisateurs le demande, le developpeur intègre PCC et LLVM.

      http://compbench.sourceforge.net/cgi-bin/index.cgi
      ps : le site n' est pas remis à jour, mais le projet continue d' avancer : aux dernière nouvelles compbench a subi un énorme remaniement, et on aura peut être même une nouvelle interface en qt4)

      Cordialement

  • # Informations

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

    Je viens de lire cet article sur ce beau projet que je ne connaisssait absolument pas et je me pose une qestion : Pourrait-on se servir de LLVM afin de créer un émulateur pour un processeur donné ?
    Par exemple, je voudrais interpréter du code ARM sur un PC x86 sous linux, est-ce que LLVM peut m'aider à créer l'interpréteur de code ARM avec des fonctionnalités de JIT ou alors je n'ai rien compris ?

    Merci d'avance pour les réponses.

    • [^] # Re: Informations

      Posté par  . Évalué à 6.

      L'idée serait de traduire le code ARM en bytecode LLVM, sachant que LLVM est capable d'appliquer des optimisations performantes sur ce bytecode. Quelqu'un s'était déjà penché sur la question pendant un Google SoC, ça a donné LLVM/QEMU (http://code.google.com/p/llvm-qemu/). Le but était de remplacer "dyngen" (*). Par contre je ne sais pas ce que ça vaut et le projet n'a plus l'air très vivant (Au niveau de QEMU ils sont partis sur un backend appelé TCG pour Tiny Code Generator en remplacement de "dyngen").

      (*) Dyngen était considéré comme un "hack", et avait tendance à ne pas fonctionner sur les GCC >= 4.

Suivre le flux des commentaires

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