Développeur : LLVM 2.2 : Un concurrent pour GCC ?
Posté par patrick_g (page perso, ). Modéré le 18 février 2008.
LLVM n'est pourtant pas tout à fait comparable au compilateur GCC. En effet GCC est un projet complet et monolithique car Richard Stallman a choisi explicitement de ne pas le rendre modulaire afin de ne pas permettre a des programmes propriétaires de s'interfacer avec lui.
LLVM au contraire est placé sous licence BSD et a choisi une conception très modulaire afin d'être réutilisé au maximum par tous. Il se limite à des fonctions d'optimisation et de génération de binaire ; il ne peut analyser lui-même le code source des programmes à compiler (c'est le projet Clang qui est prévu pour ça).
Il sera intéressant de voir ce qui va se passer sur le long terme dans l'écosystème du libre et si LLVM va être capable d'attirer des développeurs utilisant actuellement GCC.
![[en]](../images/en.png)
Les nouveautés de LLVM 2.2 (633 hits)-
Tutoriels pour LLVM (529 hits)
-
Clang (356 hits)
> Lire la dépêche (173 commentaires, moyenne: 2,8).
Vous avez demandé le commentaire #906247.
Run by 
Cette page a été générée par Templeet en 0.0566s (dont 0.0056 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
questions
A la lecture de la news, j'ai quelques point que je ne comprend pas.
J'avais cru comprendre que LLVM transformait un code intermédiaire en assembleur.
Un frontend (gcc, clang) se chargeant de convertir le langage source utilisé dans ce langage intermédiaire.
Or dans ce cas, comment un changement du frontend améliore les performance [1]. Il génère un code intermédiaire plus détaillé ?
On nous parle de type "long double" supporté par LLVM, mais c'est pas plutôt le boulot du frontend de supporter les types du language qu'il parse ? Après lecture des release note, la modif est bien dans llvm-gcc.
On nous parle pas du tout de bibliothèque rattaché au langage.
Par exemple quelle libc llvm-gcc/clang supporte ?
Ou sera l'équivalent de libgcc (qui par exemple implémente le support des flottants en soft pour les archi qui ne l'ont pas) ?
PS :
Un inconvénient à LLVM est qu'il n'est pas bootstrapable facilement, c'est à dire qu'il aura toujours besoin que le système de destination ai déjà un compilo c++.
[1]
Le frontal utilisé passe de GCC 4.0 à GCC 4.2 afin d'améliorer les performances.
[^]Re: questions
Or dans ce cas, comment un changement du frontend améliore les performance [1]. Il génère un code intermédiaire plus détaillé ?
GCC fonctionne un peu comme LLVM : il a un code intermédiaire dans lequel est traduit le code venant du front-end (Gcc, Gcj, Ada, G++, etc ...), ce code est ensuite traduit dans l'assembler cible, après avoir été optimisé.
Je suppose que LLVM s'est fait un mode GCC dans lequel l'assembleur cible est le bytecode LLVM. Bien évidemment, il profite des optims du processus de compilation de GCC.
On nous parle de type "long double" supporté par LLVM, mais c'est pas plutôt le boulot du frontend de supporter les types du language qu'il parse ? Après lecture des release note, la modif est bien dans llvm-gcc.
Je suppose que c'est un problème de gestion du 64 bits dans l'assembleur cible (ie. LLVM), dans laquelle la gestion du "plus que 32" doit être un problème, à cause de la "sérialisation" de ce genre de nombre sur deux valeurs de 32 bits.
[^]Re: questions
Je suppose que c'est un problème de gestion du 64 bits dans l'assembleur cible (ie. LLVM), dans laquelle la gestion du "plus que 32" doit être un problème, à cause de la "sérialisation" de ce genre de nombre sur deux valeurs de 32 bits.
Non, ca doit être dans le front-end, ca fait un moment que le bitcode de llvm supporte des entiers de taille arbitraire.
[^]Re: questions
Je suppose que LLVM s'est fait un mode GCC dans lequel l'assembleur cible est le bytecode LLVM. Bien évidemment, il profite des optims du processus de compilation de GCC.
Ha, dans ce cas ça fait un truc quand même assez tordu :
- gcc converti le langage dans sa representation interne.
- Il fait des optimisation dessus (générique et propre à la cible). Dans notre cas c'est quoi la cible LLVM ou l'archi finale ?
- Ensuite cette representation serait converti en bytecode LLVM.
- Ce bytecode serait ensuite retransformé par LLVM.
- Puis on générerait enfin le code assembleur.
Et comment il vont faire avec clang ?
[^]Re: questions
Je pense que seul le frontend de GCC est utilisé. C'est vraiment trop tordu autrement!!
En plus le besoin pour LLVM serait reduit: Refaire 2 fois toutes les optimisations? Faire toutes les conversions entre les formats internes de GCC? Quelle perte de temps lors de la compilation!!
clang va transformer directement le code C vers représentation intermédiaire de LLVM. Regarde le tutoriel de la création d'un front end pour avoir une idée de comment c'est réalisé.
[^]Re: questions
> Or dans ce cas, comment un changement du frontend améliore les performance [1]. Il génère un code intermédiaire plus détaillé ?
Les notes de version en anglais, ne parlent pas d'amélioration des performances grâce au changement de front end gcc.
> On nous parle de type "long double" supporté par LLVM, mais c'est pas plutôt le boulot du frontend de supporter les types du language qu'il parse ? Après lecture des release note, la modif est bien dans llvm-gcc.
Oui pour les types propres au langage, mais il faut également qu'ils disposent d'un équivalent dans le middle end. Apparemment, c'est ce qui a été implémenté ici: un équivalent du type "long double" pour l'IR (la représentation interne) de LLVM. Ensuite, cela se traduit au niveau utilisateur par un support du type C "long double" tel qu'on l'attend de la part du compilateur.
> On nous parle pas du tout de bibliothèque rattaché au langage.
> Par exemple quelle libc llvm-gcc/clang supporte ?
http://llvm.org/releases/2.2/docs/ReleaseNotes.html#portabil(...) :
# Intel and AMD machines running on Win32 using MinGW libraries (native).
# Intel and AMD machines running on Win32 with the Cygwin libraries (limited support is available for native builds with Visual C++).
Pour linux je suppose qu'ils utilisent les librairies standard de GCC, llvm-gcc n'étant qu'un compilateur après tout.
> Ou sera l'équivalent de libgcc (qui par exemple implémente le support des flottants en soft pour les archi qui ne l'ont pas) ?
hé bien justement il n'y a pas d'équivalent:
llvm-gcc 4.2 supports CellSPU as a 'configure' target and progress is being made so that libgcc.a compiles cleanly. Notable pieces still in development include full 64-bit integer and full double precision floating point support.[^]Re: questions
hé bien justement il n'y a pas d'équivalent:
llvm-gcc 4.2 ...
Oui mais à terme ils comptent abandonner gcc ? Non ?
[^]Re: questions
Je pense que oui, mais ils ne peuvent pas tout faire d'un coup.
J'aurais peut être du écrire: "pour le moment il n'y a pas encore d'équivalent".