Ouverture du code de CFE, un nouveau frontend C/C++ et sortie de l'infrastructure de compilation LLVM 2.0

Posté par Pierre Palatin (site web personnel) le 12 juillet 2007 à 12:51. Modéré par Pascal Terjan.

Étiquettes :

juil.

2007

Apple vient d'ouvrir le code de son nouveau frontend nommé "CFE". Ce frontend permet de parcourir du code C/C++/ObjC++ afin de produire un arbre de syntaxe (AST) qui permet ensuite à un compilateur de travailler dessus. Actuellement, CFE est dans un état préliminaire, n'ayant qu'un support partiel du C, mais semble avancer à grand pas. Ce frontend est avant tout destiné à LLVM (Low Level Virtual Machine).

LLVM, qui vient de sortir récemment en version 2.0, est une infrastructure de compilation libre complète ayant la particularité de mettre en avant son format intermédiaire de manière explicite, contrairement à GCC qui le garde uniquement en interne. Ainsi, il est possible de distribuer un programme sous ce format intermédiaire, qui pourra ensuite être exécuté partout. Cette approche est un peu similaire à l'approche de Microsoft avec le MSIL de .Net, mais vise ici clairement l'objectif d'avoir une performance native.

Cette représentation intermédiaire peut notamment être transformée en C, interprétée, exécutée en JIT ou compilée en natif; les performances obtenues dans ces dernier cas peuvent êtres proches de celles de GCC.

LLVM 2.0 permet désormais compiler des codes réellement complexes tels que Mozilla, Qt ou Koffice. Un backend MSIL expérimental est également fourni. LLVM, crée à l'UIUC et maintenant notamment développé par Apple fournit une infrastructure modulaire de compilation, avec une gestion souple et fine des passes de transformation, depuis le parsing jusqu'à la génération de code natif, en passant par de l'optimisation au moment de l'édition de lien.

LLVM fournit (entre autres) une bibliothèque pour manipuler et produire du code; il devient ainsi aisé de faire des systèmes de génération de code qui bénéficieront des optimisations du compilateur, telles que de l'inlining ou optimisation au moment de l'édition de lien; ainsi, Apple utilise cette approche pour OpenGL dans Leopard. De même, un projet Google Summer of Code essaye actuellement d'utiliser la génération dynamique de code dans Qemu, à la place du système actuel de génération de code ad-hoc basé sur GCC 3.

A noter qu'un des créateur et développeur principal de LLVM est Chris Lattner, qui n'était autre que le créateur de la Sabre OS Page que certains ici connaissent peut-être.

Actuellement, pour pouvoir analyser le code C/C++, LLVM utilise une version modifiée du frontend de GCC, produisant du code dans la représentation intermédiaire de LLVM. Cependant, le code de GCC n'étant pas très souple, la maintenance est difficile et l'expressivité faible. Ainsi, le passage à GCC 4.2 vient seulement de débuter.

Dans une présentation au meeting développeur LLVM (slides,vidéo), Steve Naroff explique en détail le pourquoi de la création d'un nouveau frontend. En pratique, celui-ci apportera plusieurs avantages :

Avoir un frontend facilement réutilisable, comme par exemple pour les outils d'indexation de code des IDEs, en évitant toute incohérence entre l'interface et le compilateur ;
Aisément concevoir des outils d'analyse et transformation de code, chose difficile à faire actuellement, particulièrement en C++ ;
Pour les chercheurs, il sera possible de facilement modifier la syntaxe C++ afin d'expérimenter diverses idées, chose également difficile actuellement avec GCC ;
Enfin, CFE permettra d'avoir des messages d'erreur beaucoup plus précis que GCC, et, à priori une meilleure performance sur des gros fichiers.

LLVM est un projet intéressant, ayant une approche modulaire extrêmement utile pour les outils de manipulation de code qui prolifèrent. De plus, contrairement à beaucoup de compilateurs de niche ou venant de la recherche, LLVM 2.0 est réellement utilisable dans des cas complexes réels. Comme LLVM a fait le choix du C++, le nouveau frontend ne sera probablement jamais directement intégré dans GCC; cependant, il reste très intéressant par sa souplesse et modularité et deviendra probablement un incontournable pour tout les outils de manipulation de code et autres approches expérimentales.

Aller plus loin

Annonce de CFE (41 clics)
LLVM Compiler Infrastructure (43 clics)
Notes à propos de LLVM 2.0 (43 clics)
Performances de LLVM 2.0 et gcc 4.2 (45 clics)

# Petite remarque ...

Posté par lasher le 12 juillet 2007 à 14:40. Évalué à 4.

AST = « Abstract Syntax Tree », soit arbre de syntaxe abstrait . Ce dernier mot a son importance !
- [^] # Re: Petite remarque ...
  
  Posté par mickabouille le 12 juillet 2007 à 18:57. Évalué à 4.
  
  Je n'ai d'ailleurs jamais compris pourquoi "abstrait". Ce type d'arbre n'est pas plus abstrait que des centaines d'autres types d'arbres.
  - [^] # Re: Petite remarque ...
    
    Posté par pasSteve pasJobs le 12 juillet 2007 à 19:01. Évalué à 7.
    
    Je suspecte fortement que la traduction correcte d'AST soit « arbre de syntaxe abstraitE », en opposant la syntaxe abstraite à celle, concrète, du fichier source.
# Petite explication ?

Posté par chimai le 12 juillet 2007 à 16:30. Évalué à 2.

L'article a l'air fort intéressant, mais est malheureusement bien trop technique pour moi... Serait-il possible de rajouter une courte explication destinée aux néophites ?

En gros, ça permet de créer des binaires pouvant tourner sur toutes les plate-formes, c'est ça ?
- [^] # Re: Petite explication ?
  
  Posté par reno le 12 juillet 2007 à 18:25. Évalué à 3.
  
  Non, LLVM est moins porté que GCC (normal, il est plus récent).
  
  Un compilateur contient grosso-modo 2 partie: un frontal qui analyse le code, et une back-end (dorsale? beurk!) qui génère le binaire pour l'ordinateur.
  
  LLVM peut remplacer la back-end de GCC, et Apple vient de libérer un frontal indépendant de GCC, donc ça fait un nouveau compilateur 'entier' libre..
  
  Maintenant quand a expliquer l'interet de LLVM par rapport a la backend de GCC de manière simple, la je ne sais pas faire..
  - [^] # Re: Petite explication ?
    
    Posté par pasSteve pasJobs le 12 juillet 2007 à 18:50. Évalué à 2.
    
    Non, LLVM est moins porté que GCC (normal, il est plus récent).
    
    Ce qu'il veut dire, je pense, c'est que LLVM peut compiler directement son IR en assembleur natif (ou même en C bas niveau ou CIL/MSIL), quelle que soit la machine sur laquelle tu es, juste en spécifiant une option sur la ligne de commande.
    
    À l'inverse, GCC est beaucoup moins modulaire, à ma connaissance il faut tout compiler à part pour construire un cross-compilateur.
    
    Toutefois, attention : ce n'est pas très clair dans la dépèche, mais l'IR LLVM n'est portable que dans la mesure ou le front-end qui le génère s'en assure. À l'heure actuelle, l'IR produit par llvm-gcc n'est pas du tout portable[0] vu que le C/C++ ne l'est pas (taille des données dépendant de l'architecture, etc), donc il ne faut pas espérer distribuer un programme compilé via llvm-gcc vers le « bitcode » LLVM sur d'autres architectures.
    
    [0] : http://lists.cs.uiuc.edu/pipermail/llvmdev/2005-June/004450.(...) par exemple.
    - [^] # Re: Petite explication ?
      
      Posté par Pierre Palatin (site web personnel) le 12 juillet 2007 à 22:35. Évalué à 3.
      
      Non, en pratique ce qui est dit dans le thread c'est que le frontend C typiquement va compiler en dur le code. Ainsi par exemple, un sizeof(long) transformé par un llvm-gcc 64bits donnera '8' et un 32bits donnera '4' quelque soit l'interpreteur/JIT/compilo de représentation intermediaire utilisé (garanti testé à l'instant :). Donc le risque principal est un problème d'optimisation si jamais les plateformes sont trop différentes - mais probablement rien de trop violent souvent. Le code devrait continuer à fonctionner quelque soit l'host.
      
      Après, effectivement, il est possible de faire des trucs gore en C/C++ et il est probablement possible d'introduire des bugs de cette manière; mais il s'agit de bugs du programme, qui seraient apparus de la même manière si le programme avait été recompilé "normalement" pour une autre archi.
      
      (après je suis pas vraiment un utilisateur de LLVM autrement que pour des tests, donc je peux me tromper; mais c'est ce qui est dit dans le thread en question & les docs et c'est cohérent avec l'interpréteur que j'ai décortiqué)
# LLVM & OpenGL/Mesa

Posté par Sebastien le 12 juillet 2007 à 18:34. Évalué à 4.

Apple utilise cette approche pour OpenGL dans Leopard

J'avais lu recemment un billet de Zack Rusin a propos de LLVM et MESA:
http://zrusin.blogspot.com/2007/05/mesa-and-llvm.html

Interessant, comme d'hab'
- [^] # Re: LLVM & OpenGL/Mesa
  
  Posté par benoar le 13 juillet 2007 à 11:11. Évalué à 4.
  
  De ce que j'ai compris, Apple l'utilise dans le cas où la carte ne sait pas faire de shaders en hard, et se sert de LLVM pour adapter le code des shaders au CPU en optimisant dynamiquement.
  
  Par contre, dans e lien que tu files pour Mesa, Zack Rusin parle d'adapter un back-end à LLVM pour les GPU ! Ce qui me semble encore plus fou et je ne sais pas si c'est encore faisable, cf ce lien dans les commentaires :
  http://lists.cs.uiuc.edu/pipermail/llvmdev/2007-May/009110.h(...)
  En gros, leur code remplace le compilateur GLSL par un "optimisateur" dynamique de shader pour GPU ... ! Bon, à priori ce n'est pas encore complètement au point (i.e. le back-end pour GPU n'existe pas encore il me semble, ils n'ont qu'un back-end "soft" (CPU) pour le moment...), mais ça a l'air prometteur.
# LLVM plus rapide que GCC

Posté par loufoque le 15 juillet 2007 à 20:18. Évalué à 3.

La dépêche dit que les performances de LLVM sont proches de GCC, laissant suggérer que LLVM est quelque peu plus lent.
C'est faux : le code compilé par LLVM est bien plus rapide qu'avec GCC, simplement parce que LLVM fait des optimisatons plus poussées, en particulier à l'édition de liens.

Le format intermédiaire de LLVM, de type SSA, a justement été choisi car il permettait la mise en place des tous derniers algorithmes d'optimisations issus de la recherche.

LLVM a, comme il a été dit dans un autre message, été choisi par le projet Mesa, qui va en faire des backends pour les cartes graphiques modernes. Ce qui signifie qu'à terme on pourra exécuter, en plus de GLSL, du C ou même du Python, le tout optimisé, sur son GPU.
- [^] # Re: LLVM plus rapide que GCC
  
  Posté par pasSteve pasJobs le 15 juillet 2007 à 21:25. Évalué à 4.
  
  C'est faux : le code compilé par LLVM est bien plus rapide qu'avec GCC, simplement parce que LLVM fait des optimisatons plus poussées, en particulier à l'édition de liens.
  
  Preuves ? Benchs ?
  
  Le format intermédiaire de LLVM, de type SSA, a justement été choisi car il permettait la mise en place des tous derniers algorithmes d'optimisations issus de la recherche.
  
  L'IR du « middle-end » de GCC, Gimple, est aussi en forme SSA depuis la branche 4.x. Il a remplacé RTL pour la plupart des optimisations de haut niveau.
  - [^] # Re: LLVM plus rapide que GCC
    
    Posté par Antoine le 16 juillet 2007 à 01:19. Évalué à 1.
    
    Preuves ? Benchs ?
    
    Clique sur le dernier lien de la dépêche.
    - [^] # Re: LLVM plus rapide que GCC
      
      Posté par pasSteve pasJobs le 16 juillet 2007 à 11:12. Évalué à 0.
      
      Le premier lien c'est http://lists.cs.uiuc.edu/pipermail/llvmdev/2007-July/009817.(...) je suppose que tu parles plutôt de http://lucille.atso-net.jp/blog/?p=294 ?
      De plus, il y a un s à Benchs, tu juges la qualité d'un compilateur à un seul bench ? Si on va par là, j'ai essayé avec nbench[0] et le dernier LLVM-GCC stable + LLVM 2.0 sont battus à plate couture par GCC 4.2.
      
      [0] : http://www.tux.org/~mayer/linux/bmark.html
      - [^] # Re: LLVM plus rapide que GCC
        
        Posté par Antoine le 17 juillet 2007 à 15:09. Évalué à 2.
        
        De plus, il y a un s à Benchs, tu juges la qualité d'un compilateur à un seul bench ?
        
        Non mais c'est au moins un début de réponse à ta question. :)
  - [^] # Re: LLVM plus rapide que GCC
    
    Posté par loufoque le 21 juillet 2007 à 17:03. Évalué à 1.
    
    Preuves ? Benchs ?
    
    http://llvm.org/nightlytest/
    Choisis une machine, clique sur "view details", puis sur "full test results", puis regarde la colonne GCC/LLC.
    Une valeur supérieure à 1 signfie que LLVM est plus rapide.
    
    De plus, moi qui aime bien regarder l'assembleur généré par mes programmes, je remarque qu'avec LLVM il y a une bien meilleure propagation des constantes et un meilleur inlining.
    Ça inline même les fonctions virtuelles... chose dont GCC est incapable.

Suivre le flux des commentaires

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