Journal test de llvm

Posté par  .
Étiquettes : aucune
15
15
mar.
2009
Après la nouvelle version de llvm, je me suis dit que ça pourrait être sympa de la tester.

Comme au moment du test, la 2.5 n'était pas dispo sur ma distrib et que clang n'est pas disponible, je passe par l'étape de compilation.

Je tente d'utiliser la 2.5, mais il n'y a pas de version stable de clang, et il faut forcement utiliser la version de dev (subversion).

La compilation se passe bien, je décide de faire un test sur ffmepg.

Et la les problèmes commencent :
le script de build arrive bien a utiliser ccc le frontend clang, il y a juste un mineur soucis avec la génération des dépendances qui n'est pas supporté par clang.

La compilation se passe bien, jusqu'à tomber sur un assert de llvm [1]. Le bug est signalé et corrigé assez vite.
La compilation se poursuit jusqu'à tomber sur un problème de compilation avec l'asm-inline [2]. Le problème est signalé et en attendant sa résolution, je modifie les sources pour le contourner.

Ça y est, j'ai réussi a compiler ffmpeg avec llvm/clang. Je lance les tests de régression. Et un test échoue lamentablement. Après analyse le code est mal compilé [3].

Je me dis que j'ai peut être été trop ambitieux de vouloir tester clang, donc je teste llvm-gcc. Je le compile pour être sur la même base que clang.
Et a la compilation de ffmpeg, llvm-gcc crash [4].

Je reviens à [3] et je constate que le bug n'apparait pas en -O0, je décide de compiler ffmpeg en -O0 (en plus ça me permettra d'avoir les symboles de debug, chose que llvm ne sait pas faire en -Ox [5]).
Mais en -O0 tout le code ne compile pas [6].

En désactivant les optimisations assembleur j'arrive enfin à compiler un ffmpeg (lent) qui passe les tests de régression...


Le tout, plus le fait que llvm ne suit pas forcement l'ABI linux [7], m'a vraiment déçu.
Je pensais que llvm était dans une version bien plus avancée et stable.




[1] http://llvm.org/bugs/show_bug.cgi?id=3759
[2] http://llvm.org/bugs/show_bug.cgi?id=3788
[3] http://llvm.org/bugs/show_bug.cgi?id=3789
[4] http://llvm.org/bugs/show_bug.cgi?id=3787
[5] http://llvm.org/bugs/show_bug.cgi?id=1710
[6] http://llvm.org/bugs/show_bug.cgi?id=3800
[7] http://llvm.org/bugs/show_bug.cgi?id=3731
http://llvm.org/bugs/show_bug.cgi?id=783
http://llvm.org/bugs/show_bug.cgi?id=2823
http://llvm.org/bugs/show_bug.cgi?id=2390

  • # Options de compilation

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

    Pour tout abonnement au journaux de DLFP ... la page man de llvm est offerte en cadeau

    Ne ratez pas le prochain numéro avec la page man de /etc/motd

    • [^] # Re: Options de compilation

      Posté par  . Évalué à 10.

      Le monsieur au moins il contribue en faisant des rapports de bugs. Je trouve que ce genre de comportement devrait être récompensé et non sanctionné par un commentaire acerbe.

  • # ffmpeg

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

    Je pense que le pb vient de ton choix de ffmpeg qui est quand même un soft bien spécial avec toutes ces routines hyper optimisées.
    Tu a essayé de compiler un autre truc ?

    En tout cas super journal, bien intéressant et bravo pour les rapports de bug.

    • [^] # Re: ffmpeg

      Posté par  . Évalué à 2.

      ça parait évident ... surtout que l'objectif de LLVM n'est pas de remplacer gcc.

      • [^] # Re: ffmpeg

        Posté par  . Évalué à 0.

        Ce n'est pas ce que dit la dernière dépêche de dlfp :
        http://linuxfr.org/2009/03/04/25108.html
        Du côté du projet Clang qui est destiné à remplacer GCC dans les futures versions

        • [^] # Re: ffmpeg

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

          Heu je pense que ce n'est pas du tout ce que ca veut dire.

          LLVM utilise actuellement GCC. Clang est destiné à remplacer GCC pour l'utilisation de LLVM

          • [^] # Re: ffmpeg

            Posté par  . Évalué à 1.

            Ce journal porte sur llvm+clang et il teste les deux ensembles.
            Certes, un comparatif *aujourd'hui* sera en faveur de gcc.

            Pour en revenir à la dépêche, elle est clairement llvm vs gcc. Je t'invite à la relire. Les modérateurs auraient fait une boulette ?

            > Clang est destiné à remplacer GCC pour l'utilisation de LLVM

            Oui. Mais llvm+clang se veut un "remplaçant" de gcc. Plus précisément, une alternative. Matthieu C a tenté d'évaluer cette alternative.

            • [^] # Re: ffmpeg

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

              La dépeche disait en première partie 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.
              Et plus loin dans les détails ca dit Du côté du projet Clang qui est destiné à remplacer GCC dans les futures versions, il y a aussi du nouveau, sous entendu remplacer GCC dans les futures versions de LLVM.

              En ce qui concerne ce journal, oui c'est une alternative et c'est intéressant de savoir ce qu'il est possible de faire avec aujourd'hui, mais le but de LLVM n'est pas de reeccrire GCC pour avoir un remplaçant qui sache compiler ce que GCC sait actuellement compiler. Dans ce sens il n'est pas destiné à remplacer GCC. Je pense que le nouveau pcc par contre a plus cet objectif.

              • [^] # Re: ffmpeg

                Posté par  . Évalué à 3.

                > Dans ce sens il n'est pas destiné à remplacer GCC

                Je n'ai pas dit qu'il était destiné à remplacer GCC ou que c'était son objectif.
                C'est un peu léger de réfuter toute critique de llvm+clang en disant que ce n'est pas un remplaçant de gcc ni que c'est son objectif. Ils proposent les mêmes fonctionnalités, donc on les compare.

                > Je pense que le nouveau pcc par contre a plus cet objectif.

                Pour BSD.

            • [^] # Re: ffmpeg

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

              Je pense que l'amgiuité viens de la manière d'interpréter "remplacer".

              L'objectif de clang++llvm me semble quand même de faire un compilateur C et dérivés au moins aussi bon que gcc et même meilleur grâce à toutes les possibilités offertes par llvm.

              Par contre, l'objectif, et c'est relativement clair dans les propos des dévellopeurs, n'est pas de faire un remplacant direct de gcc, dans le sens un compilateur qui accepte les mêmes sources et donne les même binnaires.

              Un programme écrit en respectant les standards devrait être accepté par les deux sans problèmes, mais tout ce qui touche aux extentions des standards ne sera pas forcément géré de la même manière.
              Les extentions spécifiques à gcc ne seront pas forcément gérées de la même manière.
              L'objectif de clang est quand même de faire un compilateur propre en partant sur des bases saines. Dans ce cadre, il y a des choses relativement dégueulasse faites par gcc qui ne peuvent pas être supportées.

              Donc ici, il faut clairement prendre "remplacant" comme "alternative", c'est-à-dire un compilateur aussi bon (voir meilleur) mais pas forcément compatible à 100% si tu utilise des trucs spécifiques à gcc. Tout comme gcc est une alternative à icc ou visual-c mais pas 100% compatible.

              Pour ce qui est de la non-compatibilité avec l'ABI de linux, si j'ai bien compris elle n'est que temporaire. Une grosse partie du dévellopement ce fait sous darwin qui n'a pas la même ABI d'ou cette incompatibilité, mais à terme les deux devrait être supportées.

    • [^] # Re: ffmpeg

      Posté par  . Évalué à 3.

      Je pense que le pb vient de ton choix de ffmpeg qui est quand même un soft bien spécial avec toutes ces routines hyper optimisées.
      C'etait le but : tester avec quelque chose de different que le hello word ou un mini bench

      De plus si tu regarde le testcase du bug [3], tu veras que c'est du C99 parfaitement valide. Sans aucune extension gcc. D'ailleurs a ce niveau ffmpeg est assez portable dans le fait que le script de configure délecte se que supporte le compilo, et n'activera l'asm inline que si celui-ci est supporté.

      Tu a essayé de compiler un autre truc ?
      Le noyau Linux, mais je suis pas allé très loin.

      Mais bon il faut croire que ca marche chez des gens : http://wiki.freebsd.org/BuildingFreeBSDWithClang


      [3] http://llvm.org/bugs/show_bug.cgi?id=3789

  • # Pluribus pluralum est.

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

    > Le tout, plus le fait que llvm ne suit pas forcement l'ABI linux [7], m'a vraiment déçu.

    Ben, LLVM, ça doit tourer soit linux, *bsd, beos, windows, cygwin, et autres que j'oublie non ?
    Si tel est le cas, alors "heureusement" que ça ne suit pas l'ABI linux, tu crois pas ?

    En tout cas ça a l'air fun…

    • [^] # Re: Pluribus pluralum est.

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

      Justement le fait que ça doit tourner sous toutes ces plateformes fait qu'il doivent supporter leurs ABI respectives. Si ce n'était pas le cas, ce serait génant pour compilé une lib dynamique par exemple.

      La seule chose c'est que pour l'instant c'est l'ABI de darwin la mieux supportée car le dévellopement est fait principalement sur ce système.

      • [^] # Re: Pluribus pluralum est.

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

        Haa.
        J'avais mal compris, je pensais à API, donc oui, effectivement, c'est pas top si ça colle pas.
        Forcément, si fallait une API différente par hôte, ça rendait le truc con, et je comprenais vraiment pas le problème.

        Maintenant, l'ABI du noyau linux varie-t-elle beaucoup ?
        J'imagine alors que chaque version de LLVM est compatible avec certains noyaux uniquement non ?
        Enfin, le programmeur qui compile vers LLVM, il s'en fiche de l'ABI non ? Ou alors ça veut dire que si elle est pas complète pour tel ou tel hote, il va falloir compiler le code vers LLVM sans utiliser les parties "cassées" de la VM ? Par exemple (fictif), si l'additionneur ternaire est pas implanté, compiler en (+ a (+ b c)) au lieu de (+ a b c) ? Ou alors tout simplement ça sera émulé d'une manière ou d'une autre ?

        (euh, je me suis pris gros en moinssage pour ma question du message précédent, je pige pas trop là.)

        • [^] # Re: Pluribus pluralum est.

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

          Le problème n'est pas tellement l'interface avec le noyau, mais surtout l'interface avec les bibliothèques compilées avec autre chose que LLVM. En gros, la compatibilité au niveau ABI, ça permet de faire des appels de fonctions d'un binaire à l'autre (donc d'un programme vers un .so, ...).

  • # Petit commentaire

    Posté par  . Évalué à 1.

    Juste histoire de dire que je n'ai pas lu ton journal en entier pour une raison simple : tu n'as pas expliqué ce qu'était llvm.
    Sans rentrer dans les détail, juste une petite phrase pour dire aux incultes comme moi ce qu'est cet outil...

    • [^] # Re: Petit commentaire

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

      Il y a eu de nombreuses dépêches sur linuxfr au sujet de llvm. Si tu ne les as pas lues, qu'est-ce qui t'empêche de te renseigner en deux minutes sur google? C'était un journal, pas une dépêche...

      • [^] # Re: Petit commentaire

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

        Perso, j'appuie la remarque initiale. Perso, j'ai lu toutes les dépêches Linuxfr parlant de llvm. Mais les compilateurs n'étant pas vraiment mon domaine de prédilection, je ne les ai pas forcément en tête.
        Alors en cliquant sur ce journal, je m'attendais à lire un journal parlant de LVM (Logical Volume Manager), et pas du tout à un compilo. Et pendant les premières lignes, j'avais vraiment du mal à faire le lien entre LVM et les tests de Matthieu C.

        Donc oui, quand on parle d'une appli non triviale, trois/quatre mots de rappel serait un plus agréable.

        • [^] # Re: Petit commentaire

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

          Alors en cliquant sur ce journal, je m'attendais à lire un journal parlant de LVM

          Donc tu reproches au rédacteur du journal ta myopies ? Il est écrit LLVM.

          ===>[-0]

  • # A tester aussi, l'interpreteur compilateur JIT lli

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

    Tu devrais aussi tester le compilateur JIT lli en émettant un fichier bitcode ".bc" avec llvm-gcc puis en lancant l'interpreteur sur ce fichier:

    % llvm-gcc --emit-llvm-bc -c -o mon_programme.bc mon_programme.c
    % lli mon_programme.bc

    ou si tu as des dépendances chargées dynamiquement :

    % lli --load=/chemin/vers/mes/libs.so mon_programme.bc

    En 2.4, j'ai observé des segmentation faults sur un programme compilé avec llvm-gcc en code natif que je ne reproduisais ni avec le vrai gcc, ni avec la version bitcode interpretée par lli (valgrind n'a pas vu l'erreur non plus). J'ai pas eu le courage de compiler la version 2.5 pour voir si c'etait toujours le cas.

  • # Un autre test : Blender

    Posté par  . Évalué à 3.

    Un internaute s'est amusé à compiler Blender avec Clang + LLVM et à comparer les différents rendus 3D de diverses scènes, aussi bien au niveau du temps nécessaire que du résultat final. Globalement il semble y avoir plus de gains de performance que de pertes, mais d'un autre coté de nombreux artefacts apparaîssent sur les images produites...

    Le mail à l'origine : http://lists.cs.uiuc.edu/pipermail/cfe-dev/2009-March/004610(...)
    Les résultats : http://t1.minormatter.com/~ddunbar/blender/times.html

Suivre le flux des commentaires

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