LLVM 3.1 et Conférence EURO-LLVM 2012

Posté par  . Édité par rewind, baud123, Sylvestre Ledru, Nÿco, Florent Zara, patrick_g et Benoît Sibaud. Modéré par Florent Zara. Licence CC By‑SA.
55
23
mai
2012
Technologie

LLVM est une suite de compilation, c'est-à-dire un ensemble de bibliothèques et d'outils pour construire des compilateurs, des assembleurs, des éditeurs de liens, etc. Et quand on parle de LLVM, on parle forcément de Clang, le compilateur C/C++/ObjectiveC/ObjectiveC++ attitré du projet LLVM. Clang, par rapport à GCC, compile plus vite mais génère du code moins rapide, le vrai intérêt de Clang réside dans la clarté des messages d'erreurs.

La seconde partie de cette dépêche détaille les nouveautés de la version 3.1 de LLVM et Clang, sortie le 22 mai 2012 et propose un compte rendu de la toute première conférence Euro-LLVM (avril 2012).

LLVM et Clang 3.1 sont téléchargeables ici et respectivement (les utilisateurs de Debian Sid n'ont évidemment qu'à faire un apt-get install llvm-3.1 clang)

[NDA: un grand Merci à rewind qui a rédigé, entre autres, toute la couverture de la conf Euro-LLVM. Merci également à patrick_g, reno, Nÿco, baud123 et Sylvestre Ledru pour leurs corrections et leurs précisions.]

Sommaire

Clang

Clang est le front-end officiel de LLVM pour les langages de la famille de C. Les premiers langages pour lesquels il a atteint un niveau de « production » sont C et Objective-C (on voit là l'influence de la marque à la pomme qui a sponsorisé ce projet).
À partir de 2010, la prise en charge de C++ a progressé pour devenir excellente. La version 2.8 en octobre 2010 a apporté la compatibilité avec le standard C++03. Depuis, les efforts ont continué et Clang est désormais à la pointe en ce qui concerne le tout nouveau C++11.
Clang se démarque de gcc par la précision et la qualité de ses diagnostics, mais aussi par sa modularité : il est possible de créer ses propres outils d'analyse de code grâce à la libclang.

Nouveaux warnings

Clang est réputé pour la qualité de ses diagnostics. Cette fois-ci, plusieurs nouveaux warnings ont été ajoutés permettant une analyse encore plus précise du code source. En particulier, on notera :

-Wdangling_else

Lorsque deux if successifs sont suivis par une instruction else (dangling else), la syntaxe C/C++ prévoit que le else s'applique au if le plus imbriqué ; mais une mauvaise indentation peut induire en erreur le relecteur :

  if (foo)
    if (bar) std::cout << "case 1\n"; 
  else
    std::cout << "case 2\n";

clang++ avertit l'utilisateur en lui propose de lever l'ambiguïté :

dangling.cpp:8:3: warning: add explicit braces to avoid dangling else
      [-Wdangling-else]
 else std::cout << "case 2\n";
 ^

-Wstrncat-size

Les fonctions standard C strcpy et strcat permettent respectivement de copier et de concaténer des chaînes de caractères, mais ne permettent pas de s'armer contre des débordement de buffer provoqués par une trop grande chaîne source.
Pour remédier à cela, la bibliothèque C propose également strncpy et strncat, prenant toutes deux un argument supplémentaire de type size_t qui spécifie la taille des données à copier.
Hélas, trois fois hélas, si on peut la plupart du temps entrer la taille du buffer de destination pour strncpy, il en va autrement pour strncat. Il faut bien évidemment songer à retrancher la taille utilisée par les données déjà présentes.
Un coup d'œil sur le code historique de votre entreprise vous convaincra pourtant que les codes du type :

 strncat(dest, src, sizeof(src));

ou

 strncat(dest, src, sizeof(dest));

sont relativement répandus.
Clang repère ce type d'erreur et fidèle à son habitude, vous propose une solution :

strncat.c:8:22: warning: the value of the size argument in 'strncat' is too
      large, might lead to a buffer overflow [-Wstrncat-size]
  strncat(dest, src, sizeof(dest));
                     ^~~~~~~~~~~~
strncat.c:8:22: note: change the argument to be the free space in the
      destination buffer minus the terminating null byte
  strncat(dest, src, sizeof(dest));
                     ^~~~~~~~~~~~
                     sizeof(dest) - strlen(dest) - 1
1 warning generated.

Tout n'est pas parfait et force est de constater que clang reste muet quand le code précédent est remplacé par

strncat(dest, src, strlen(src));

Amélioration de la prise en charge de C++11 :

Les développeurs de clang ont encore amélioré la prise en charge de C++11. Les nouveautés les plus intéressantes sont :

  • les listes d'initialisation :
std::vector<int> v{1, 2, 3, 4, 5};

  • les lambda expressions :
 std::transform(v.begin(), v.end(), v.begin(),
                 [](int x){return 2 * x +1;});

  • les types littéraux définis par l'utilisateur :

Ces types peuvent avoir des utilisations intéressantes, comme par exemple la vérification statique de l'homogénéité du calcul scientifique. On peut dorénavant définir assez facilement un système d'unités et écrire des expressions du type:

Speed delorean 157715.712_m / 3600._s;//valide
Speed caddie 2_m;//erreur de compilation

Voir la keynote de Bjarne Stroustrup à la conférence « C++ Going Native 2012 » pour les détails de l'implémentation.

  • Types atomiques

Les types pour les opérations atomiques, essentielles en programmation concurrente, ont été implémentés dans clang. En conséquence, il semblerait que la libc++ ait désormais une implémentation virtuellement complète de C++11.

Fait marquant, pour la première fois, llvm propose une prise en charge plus complète que gcc du standard C++11. Clang est donc à l'heure actuelle ce qui se rapproche le plus d'un compilateur parfaitement compatible C++11. Les « exclusivités » de clang++ par rapport à gcc sont :

  • surcharge des fonctions membres pour les rvalues
  • mots clés alignas et alignof qui permettent de forcer un alignement encore plus strict que ce que fait C++ par défaut :
struct S//taille 4 sans "alignas", taille 8 avec
{
   short s0;
   short alignas(int) s1;//offset de 2 octets sans alignas, 4 octets avec
};

Prise en charge de C11

Alors que le concurrent propriétaire fait sa chochotte préfère se concentrer sur le langage C++, clang propose une prise en charge de la norme C99 quasi-exemplaire. En outre, bien que Le standard C11 soit à peine publié, l'équipe de clang a déjà commencé à le prendre en charge. Pour cette version, les développeurs ont implémenté les structures anonymes décrites dans la dépêche sortie pour la publication du standard. Ceci s'ajoute aux mots-clés alignas, generic ainsi qu'aux static_assert déjà présents dans clang 3.0

Nouvelles optimisations

Polly wants a cracker

Pour la version 3.1, LLVM se dote officiellement d'un module d'optimisation polyédrale, au joli nom de Polly. et développé par Tobias Grosser, actuellement doctorant à l'ENS. Ce garçon n'en est pas à son coup d'essai puisqu'il travaille également sur la branche Graphite qui a été incorporée dans la version 4.4 de GCC (voir la dépêche de 2009 qui propose une description précise de ce type d'optimisation). Si les résultats sont à la hauteur, on peut s'attendre à des améliorations sensibles des performances dans certains calculs matriciels.

Déroulage de boucles dynamique

Une technique classique pour optimiser les boucles est de les dérouler pendant la compilation, au prix d'une plus grande quantité d'instructions. LLVM implémente maintenant le déroulage de boucles dynamique, c'est-à-dire quand le nombre d'itérations n'est pas connu au moment de la compilation.

Placement de blocs de base

LLVM 3.0 avait permis la prise en charge de méta-données sur les branches qui permettaient d'attribuer des poids différents suivant les probabilités. Cela se traduit concrètement dans un code C par l'extension __builtin_expect() qu'on retrouve également dans GCC.

Dans LLVM 3.1, un algorithme de placement des blocs a été implémenté prenant en compte ces informations. Cela ouvre la voie à des outils similaires à gprof qui vont permettrent d'annoter le code statiquement pour permettre un meilleur agencement des blocs et donc de meilleures performances.

Back-end x86 et x86-64

Pour la version 3.0, LLVM avait déjà proposé la prise en charge des nouvelles instructions Advanced Vector Extensions (AVX), disponibles sur Intel Sandy/Ivy Bridge et sur les AMD Bulldozer. LLVM 3.1 améliore grandement cette prise en charge et ajoute celle des instructions AVX2, prévues sur les futurs processeurs Haswell d'Intel.

Euro-LLVM 2012

Les 12 et 13 avril dernier a eu lieu la première conférence européenne dédiée à LLVM. Organisée par ARM avec un soutien financier de Google et Qualcomm, de nombreux exposés ont été présentés ainsi que des ateliers pratiques autour de LLVM. Ces présentations permettent d'entrevoir le futur de LLVM ainsi que les avancées déjà intégrées pour certaines.

Introduction

Le court exposé d'introduction de Lee Smith (ARM) permet de savoir pourquoi son entreprise s'intéresse à LLVM (attention, appeaux à trolls). En fait, c'est surtout les défauts de GCC qui sont mis en avant : le code de LLVM, outre le fait qu'il soit «open source», est plus jeune donc plus facile à travailler ; LLVM a moins de contraintes techniques contrairement à GCC qui doit gérer des choix anciens ; LLVM est un meilleur framework pour fabriquer des outils d'analyse ou des langages dédiés. Autres qualités de LLVM, plutôt techniques : il peut émettre du code pour des processeurs spécialisés (DSP) propriétaires, il est capable de générer du code JIT, il est capable de prendre en charge OpenCL. Enfin, sa licence est «non-virale».

Autovectorization with LLVM

Hal Finkel du Argonne National Laboratory explique les progrès qui ont été accomplis dans l'autovectorisation. Il s'agit de transformer des couples d'instructions simples en une instruction plus complexe issue des diverses extensions disponibles (MMX, SSE*, AltiVex, NEON, etc). Comme LLVM gère depuis très longtemps dans sa représentation intermédiaire les vecteurs de registres ainsi que les opérations de base associées (addition, multiplication, etc), les différents backend qui génèrent du code machine peuvent déjà générer ces instructions. Le travail peut donc s'effectuer au niveau de la représentation intermédiaire et profiter à toutes les architectures.

Par exemple, si on a ces deux instructions simples :

%A1 = fadd double %B1, %C1
%A2 = fadd double %B2, %C2

On peut les transformer en une seule instruction en utilisant un vecteur de registre :

%A = fadd <2 x double> %B, %C

Refactoring C++ with Clang

Manuel Klimek de Google montre qu'on peut rendre C++ très amusant à l'aide d'outils adaptés. Un travail a commencé pour fournir des briques de bases et des outils pour manipuler du code C++. Les outils envisagés sont très connus mais souvent imparfaits. Ainsi Google envisage de créer un formateur de code, clang-format, qui permettrait de reformater du code selon des règles prédéfinies. Là où indent ou astyle se contentent de correction stylistique, clang-format pourrait carrément, grâce à la puissance de LLVM, s'attaquer à la syntaxe, en modifiant par exemple la casse du nom d'une fonction, dans sa définition et partout où elle utilisée ! Autre outil, clang-lint permettrait de vérifier le code à la recherche d'erreurs classiques, mais également de les corriger interactivement à la volée ! Le travail sur les bibliothèques de base a déjà commencé tandis que les outils sont encore à construire, mais sont très prometteurs.

MCJIT

Eli Bendersky d'Intel présente un débuggueur de code JIT basé sur LLVM. À noter qu'il travaille dans l'équipe OpenCL d'Intel.

Generating Serialisation Code with Clang

Wayne Palmer de Barclays Capital utilise Clang pour générer du code de sérialisation automatiquement. Dans le cadre d'une bibliothèque d'analyse quantitative utilisée par sa banque pour calculer les risques, un travail a été mené pour pouvoir générer le code de sérialisation permettant de transmettre des structures à travers le réseau, plutôt que de l'écrire à la main. Ils ont remplacé une solution basée sur Doxygen (!!!) pour une solution basée sur LLVM. Le développeur peut ainsi annoter son code C++ pour déclarer si une classe doit avoir un code de sérialisation ou pas. La principale difficulté est alors de générer le code de sérialisation au bon endroit pour qu'il soit compilé une seule fois.

Garantir que MC est correct même pour ARM

Richard Barton de ARM explique comment il a amélioré la génération de code ARM de LLVM. La génération de code dans LLVM a lieu dans un framework appelé MC pour Machine Code. Comme tout le reste dans LLVM, ce framework est très modulaire, ce qui lui permet de construire toute une série d'outils relativement simplement : assembler, désassembleur, etc. Ici, l'idée est de faire une vérification exhaustive de tous les opcodes de toutes les variantes de processeurs ARM en comparant les résultats de LLVM MC avec une implémentation de référence propriétaire de ARM. Cela représente près de 7 billions (712 ) de combinaisons possibles ! Heureusement, cet ensemble de test a été réduit pour pouvoir être exécuté en temps raisonnable. Les premiers résultats montrent qu'à peu près 10% de toutes les instructions du Cortex-A8 sont mal encodés par LLVM-MC. 14 patchs ont déjà été soumis et d'autres devraient suivre.

lld - the LLVM Linker

Michael Spencer de Sony Computer Entertainment America présente LLD, un éditeur de lien basé sur LLVM. Le but de lld est de remplacer les éditeurs de liens fournis avec le système (GNU ld ou GOLD pour Linux, ld64 pour MacOSX, link.exe pour Windows) en offrant un éditeur de lien performant, portable et surtout, qui permette de faire de l'édition de lien croisée de manière sûre. Le projet ne fait que démarrer.

Reducing dynamic compilation latency

Igor Bohm de l'University of Edinburgh utilise un ou plusieurs threads « auxiliaires » qui réalisent une compilation JIT pour optimiser les performances d'une machine virtuelle.

Compilation de Linux par LLVM

Mark Charlebois de QuIC présente les avancées de la compilation de Linux par LLVM. Le principal problème est que Linux dépend beaucoup de GCC, que ce soit à travers certains comportements comme la réaction par rapport à des options de compilations présentes ou non, ou par rapport à ces options de compilations non présentes dans LLVM, ou encore par rapport à des extensions du langage comme les tableaux de taille variable dans des structures ou les fonctions imbriquées. Sans même parler des incompatibilités spécifiques à certaines architectures comme ARM. Heureusement, tout cela est documenté pour permettre un suivi, et des patchs sont soumis.

Rappelons que dans ce même effort, Debian recompile régulièrement toute l'archive avec Clang.

Tablegen Deep Dive

Reed Kotler de MIPS présente un outil interne de LLVM : Tablegen. Cet outil, assez mal documenté, prend en entrée des fichiers de description et en ressort des morceaux de code. La syntaxe des fichiers de description est complètement générique, un peu à la manière d'XML. Pour la sortie, il est possible d'écrire des générateurs pour des tâches particulières. LLVM se sert massivement de Tablegen au niveau des générateurs de code pour documenter les registres, les instructions, les informations des architectures et de leurs variantes, etc. Ainsi, une même source d'information sert à générer diverses parties sans redondance inutile : assembleur, désassembleur, encodeur, décodeur. Cette présentation permet d'approcher un peu plus cet outil et est surtout l'occasion de lancer un effort de documentation pour permettre à Tablegen de vivre sa propre vie.

Improving Performance of OpenCL on CPUs

Ralf Karrenberg et Sebastian Hack de Saarland University montrent comment utiliser LLVM pour exécuter les kernels OpenCL sur des processeurs multicœurs actuels. Les performances sont au rendez-vous puisque l'implémentation actuelle surpasse les SDK d'Intel et d'AMD. Avec les autres avancées au niveau de l'autovectorisation, il sera bientôt possible d'avoir des kernels extrêmement performants.

Pendant ce temps, de l'autre côté de la manche

Pour ceux que LLVM intéresse, voire passionne, ou simplement ceux qui veulent boire un verre en discutant d'arbres de syntaxe abstraits, l'Initiative de Recherche et Innovation sur le Logiciel Libre (IRILL) organise l'évènement LLVM Social sur Paris. La prochaine session aura lieu ce samedi 26 mai. L'horaire et l'emplacement seront publiés incessamment sur le site d'IRILL.

Et pour l'avenir ?

Grâce à sa licence permissive modularité et sa modernité, LLVM a su générer une myriade de projets qui en font aujourd'hui un des acteurs les plus dynamiques dans le monde du développement libre.
Plus de 12 ans après sa fondation, c'est aussi l'heure de la maturité pour cette suite de compilation : de plus en plus d'industriels de premier plan (Google, Apple …) utilisent LLVM en développement ou en production. Les derniers benchmarks de Phoronix montrent que l'écart de performance entre le code généré par gcc et llvm se resserre progressivement.
Parallèlement, le projet Free-BSD annonce que clang deviendra le compilateur C/C++ par défaut pour la version 10 … coïncidence ?

Aller plus loin

  • # Aucun commentaire ?

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

    Nous avons trop bien distillé les trolls, du coup personne ne les voit :P

    • [^] # Re: Aucun commentaire ?

      Posté par  . Évalué à 8.

      Je vais en faire pour la forme.

      J'ai assisté à la présentation de LLVM par son créateur au Fosdem 2011 et l'impression que j'en ai tiré m'a fait peur. J'ai eu l'impression que le but était uniquement de battre GCC à telle point que je me suis demandé que si GCC s'arretait, est-ce que LLVM continuerait ou le but était atteint et on arrêtait.

      Cette hargne est, je trouve, rarement autant exposé entre deux projet, d'habitude on essaye de mettre son projet en avant en montrant ce qu'il fait plutôt que de le comparer sans cesse. Je ne dis pas que la comparaison est mauvaise mais qu'en abuser fait peur, ça donne l'impression qu'on ne peut pas se débrouiller seul.

      Je me souviens particulièrement de la comparaison de vitesse de compilation en disant "Regardez, même notre -O4 (que GCC n'a pas) compile plus vite que le -O3 de GCC" sans donner d'explication sur ce que faisait ce -O4, alors que ça me semble très important vu que -O3 n'est déjà pas vraiment recommandé et que si ce -O4 est inutilisable, c'est inutile d'en parler.

      « 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: Aucun commentaire ?

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

        Bah, je le vois plutôt comme une reconnaissance que GCC est (et reste) la référence. Je pense que s'ils le font, c'est aussi parce qu'on leur a beaucoup dit : «et par rapport à GCC ?». Après, si ça crée une émulation, c'est pas plus mal.

        • [^] # Re: Aucun commentaire ?

          Posté par  . Évalué à 2.

          Je pense aussi que l'émulation est une bonne chose mais il faut aussi faire des chose parce qu'elles sont bien en elle-même pas par rapport à ce que fait GCC. Si GCC annonce qu'ils sont 4x plus lent que la version précédente, j'ai l'impression que LLVM va sortir fièrement une version 8x plus lente pour exploser GCC.

          « 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: Aucun commentaire ?

            Posté par  . Évalué à 4.

            Je n'étais pas au Fosdem, mais de ce que j'ai lu et vu, ce qui attire dans llvm, ce ne sont pas forcément les super perfs (bon, évidemment, c'est un plus), mais c'est le côté « boîte à outils », et c'est là où gcc pèche, de mon point de vue. Quand on voit le nombre de gens qui s'amusent à écrire des front-ends, des projets d'analyseurs statiques customisés (j'en ai un dans ma boîte) où même des piles de traitement graphique 3D, on se dit que c'est bien là qu'on attend llvm.

            Alors, oui, le côté bataille des perfs est peut-être malsaine, mais ce serait regarder le monde llvm par le petit bout de la lorgnette que de se cantonner à cet aspect.

            Si vous avez un moment, franchement, regardez la video (lien dans l'article) de Chandler Caruth « Defending C++ from a million code monkeys » pour avoir une idée de ce qu'une boîte comme Google peut faire avec des outils un peu plus ouverts (même sans parler de la licence) et vous aurez une petite idée de pourquoi ça n'était pas possible de le faire avec gcc.

      • [^] # Re: Aucun commentaire ?

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

        La raison est peut être simple : il suffit que le sujet de son intervention à la FOSDEM soit spécialisé sur la comparaison avec GCC.
        Et oui, quand tu fais des pres chaque année à la FOSDEM, tu ne vas à chaque fois ressortir le même talk et refaire une introduction de LLVM. Tu as envie de faire des talks différents chaque année.

        Au final, tu as peut être raison, mais gaffe à ne pas te faire un avis sur seulement une conférence qui était justement là pour faire une comparaison.

    • [^] # Re: Aucun commentaire ?

      Posté par  . Évalué à 7.

      Nous avons trop bien distillé les trolls, du coup personne ne les voit :P

      En voici un premier : le dangling else est débusqué par gcc depuis (au moins) la version 4.6, LLVM ne se démarque pas de gcc sur ce point là.

  • # Fôte

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

    il semblerait que la libc++ est désormais une implémentation virtuellement complète de C++11.

    Ait. Du verbe avoir au conditionnel.

    Commentaire sous licence LPRAB - http://sam.zoy.org/lprab/

    • [^] # Re: Fôte

      Posté par  . Évalué à -1.

      nan, à la limite, soit, du verbe être au subjonctif (j'ai hésité entre le subjonctif et l'indicatif), mais certainement pas le verbe avoir.

      • [^] # Re: Fôte

        Posté par  . Évalué à 2.

        Je retire ce que j'ai dit, libc++ implémente C++11 ET C++03, donc, en toute logique le verbe avoir devrait convenir. Une rapide recherche google laisse penser que « semblerait que » appelle le subjonctif, donc ta correction me paraît valide.

        Ceci étant, je crois que « fournisse » serait plus juste.

  • # bonne interface = bon logiciel

    Posté par  . Évalué à -4.

    Il suffit que l'interface d'un logiciel soit mieux, pour que les gens l'utilise, peu importe la qualité intrinsèque de ce logiciel.

    Donc arrêtez d'ajouter des features à vos logiciels, et faites de bonnes UX ! (UX pour User eXperience (en France on parle plus d'interface homme-machine))

    Non ce message n'est pas spécialement destiné à OpenOffice. Ou a Kde. Ou a Git. Ou a Performous. Ou a…

    • [^] # Re: bonne interface = bon logiciel

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

      C'est vrai, la ligne de commande, c'est top tendance !

    • [^] # Re: bonne interface = bon logiciel

      Posté par  . Évalué à 7.

      UX pour User eXperience (en France on parle plus d'interface homme-machine)

      Ergonomie ne serait pas une meilleure traduction de UX ?

      L'UX c'est plus que l'interface à mon humble avis. Sinon faut plutôt parler d'UI ou de GUI je pense (et là oui ce sont les IHM en français).

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

  • # Vive le renouveau

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

    Perso, ca me fait plaisir de voir que un certain nombre de projets de vieux barbus se font rattraper par des projets plus jeunes et plus dynamiques. C'est rafraichissant ! Surtout qu'un truc aussi baleze qu'un compilateur multi-langage, tu peux pas trop le sortir de ton chapeau en bossant dessus soir et week-end !

    Les vieux projets ne meurent pas et gardent toutes leurs qualités et stabilité, mais les nouveaux projets arrivent et montrent qu'on peut faire plus souple, plus rapide, plus dédié ou moins contraignant sur la licence.

    Je pense à Apache et les nouveaux serveurs web, MySql et toutes les bases NoSql, Gcc et llvm, PHP et tous les nouveaux frameworks web.

    C'est un processus naturel d'un écosystème logiciel: au début, il y a rien, donc tout le monde travaille à combler le vide avec une unique solution. Et quand l'écosystème s'enrichit, on peut commencer à remettre en cause des anciens choix.

    Quel est le prochain logiciel de barbu qui va se faire dépasser par un logiciel de boutonneux ?

    • [^] # Re: Vive le renouveau

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

      Les vieux projets ne meurent pas et gardent toutes leurs qualités et stabilité, mais les nouveaux projets arrivent et montrent qu'on peut faire plus souple, plus rapide, plus dédié ou moins contraignant sur la licence.

      Le troll est bien caché mais je ne pense pas que la licence soit un facteur déterminant pour un nouveau projet face à un ancien. Il y a une tendance en ce moment à choisir des licences ultra-permissives, parce que pour l'instant, il n'y a aucun problème. Mais rien ne dit que ça continuera comme ça et ce jour là, on en reparlera. Si Apple décide un jour de «valoriser» LLVM, comme Intel valorise icc, et bien on pourra dire au revoir à ce logiciel. Certes la dernière version restera libre mais pas les suivantes et comme tu le dit, c'est pas un barbu qui bosse le soir et le week-end qui va maintenir un tel machin.

      Quel est le prochain logiciel de barbu qui va se faire dépasser par un logiciel de boutonneux ?

      Linux ? Par le HURD évidemment !

      • [^] # Re: Vive le renouveau

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

        Un rapide coup d'oeil sur la ML des commits permet de voir que Apple n'est pas du tout le seul développeur de LLVM et de son écosystème.
        Google est un gros contributeur et beaucoup d'acteurs comme Intel, ARM, MIPS, Cray ou encore NVidia contribuent au code. Tu as même des debianeux qui contribuent directement au code (par exemple, en portant LLVM sous HURD).

        En parallèle, de nombreux académiques basent leurs travaux de recheche sur LLVM et son écosystème (au hasard, Tobias dont on parle dans cette dépêche ou Inria/LIP6 avec VMKit).

        Bref, je pense pas qu'il faille avoir d'inquiétude de ce coté là…

      • [^] # Re: Vive le renouveau

        Posté par  . Évalué à 0.

        Ce serait intéressant d'avoir des statistiques comme pour le kernel Linux, pour voir dans quelle mesure Apple contribue à LLVM. Ça permettrait de savoir s'ils seraient en mesure de fermer le code source et de faire mourir le projet.

      • [^] # Re: Vive le renouveau

        Posté par  . Évalué à 5.

        Soit dit en passant, quand Intel fait du libre, c'est en GPL. La raison est simple : ils s'assurent que les concurrents ne peuvent pas modifier et distribuer le code sans contribuer en retour. Et si un concurrent vend une modif du code d'Intel version commerciale, c'est pas dur : Intel n'a qu'à acheter une licence, demander le source, et…. l'intégrer dans son propre produit GPL. :)

  • # Messages d"erreurs

    Posté par  . Évalué à 6.

    Clang se démarque de gcc par la précision et la qualité de ses diagnostics.

    Serait-it possible d'atteindre le même niveau de clarté avec GCC ou est-ce trop ancré dans les entrailles obscures du code ? Qu'est-ce qui fait que Clang propose des messages plus clairs ?

    • [^] # Re: Messages d"erreurs

      Posté par  . Évalué à 10.

      Qu'est-ce qui fait que Clang propose des messages plus clairs ?

      Je crois qu'ils modifient la luminosité de l'écran à la fin de chaque compilation.
      -->[]

    • [^] # Re: Messages d"erreurs

      Posté par  . Évalué à 4.

      Qu'est-ce qui fait que Clang propose des messages plus clairs ?
      D'aucuns avaient vu une solution dans le fait que Clang s'était comparé à la version 4.2 de gcc: http://clang.llvm.org/diagnostics.html

      Hors du troll, l'architecture de Clang y est peut-être pour quelque chose en ce sens que plus modulaire, elle doit passer beaucoup plus d'informations d'une couche à l'autre.

    • [^] # Re: Messages d"erreurs

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

      Je vois plusieurs choses :

      • Clang propose souvent un correctif pertinent : par exemple, en cas d'oubli de & (l'opérateur unaire, celui qui prend l'adresse d'une variable), il suggérera d'en ajouter un et montrera exactement où. Autre correctif, quand on fait une coquille sur un nom de variable ou de fonction, il suggère le bon nom (en montrant où est défini ce nom). Ce sont des petites choses mais ça rend le quotidien tellement plus agréable.
      • Clang a tout intégré, ce qui signifie que le préprocesseur ou l'assembleur ne sont pas des programmes à part. Du coup, il peut faire remonter l'erreur exactement où elle se situe. Si on fait une erreur dans une macro, cette erreur sera détecté à la compilation mais Clang sera capable de remonter jusqu'à la macro, alors que GCC ne pourra pas. De même pour l'assembleur inline, Clang pour remonter jusqu'au code source en cas d'erreur.

      Voilà je pense les deux principaux atouts de Clang par rapport à GCC.

  • # Backend X86

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

    Perso j'ai toujours mon problème que LLVM produit du code incompatible avec autre chose que cpu >= i686 pour de l'intel.

    Savez-vous si c'est corrigé ?

    http://llvm.org/bugs/show_bug.cgi?id=11212

    les pixels au peuple !

    • [^] # Re: Backend X86

      Posté par  . Évalué à 2.

      Sur arm aussi, llvm générait du code imprédictible pour les cpu Je sais pas si c'est toujours le cas.

      Peut etre qu'elles ont été detecté par Richard Barton, mais l'article ne parle que de cortex-A8…

Suivre le flux des commentaires

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