> 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
Posté par djano . En réponse à la dépêche LLVM 2.2 : Un concurrent pour GCC ?. Évalué à 2.
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.