Discussion :

[Hinault Romaric]

LLVM 3.2 disponible avec Clang
la suite d’outils de compilation pour C, C++ et Objective C améliore l’optimisation du code et le support de C11 et C++11

Les développeurs de LLVM viennent d’annoncer la sortie de la version 3.2 de la machine virtuelle à destination des langages de programmation, qui apporte un nombre important de nouvelles fonctionnalités et des améliorations de l’optimisation du code et des performances.

LLVM 3.2 intègre le compilateur Clang 3.2 pour les langages C, C++ et Objective C, la librairie compiler-rt, le « low-level debugger LLDB », la librairie C++ libc++ et la JVM VMKit qui utilise LLVM pour la compilation statique et JIT (Just In Time).

Cette mouture apporte une nouvelle vectorisation des boucles, qui utilise des instructions avancées qui agissent sur des ensembles de valeurs plutôt qu’une seule valeur à la fois.

Un nouveau backend NVPTX vient remplacer le backend PTX (Parallel Thread eXecution) existant. Développé par Nvidia, NVPTX est basé sur CUDA et sur le compilateur OpenCL. Il sert d’intermédiaire entre le programme CUDA et le code binaire utilisé par la carte graphique.

Le compilateur Clang bénéficie d’une meilleure prise en charge de la norme C11 et C++11, des améliorations des fonctions de diagnostics, de gestion des commentaires et de la sécurité des types sous forme d’un attribut. Il introduit également le support de l’attribut tls_model, qui permet de spécifier le modèle mémoire utilisé pour les variables locales à un thread (_Thread-Local Storage_).

LLVM 3.2 dispose également du plugin DragonEgg GCC qui permet de charger des plugins et de prendre en charge les modèles de stockage en local. DragonEgg n’a désormais plus besoin de GCC pour être compilé avec le support LTO.

Le code source de LLVM 3.2 est téléchargeable sous une licence open source sur le site du projet.

Télécharger LLVM 3.2


Source : Notes de version


Et vous ?

Que pensez-vous de ces améliorations ?

[Freem]

Si « low-level debugger LLDB » est intégré, cela veut dire qu'on pourra utiliser autre chose que GDB pour déboguer dans quelques temps?

Ce serait pas mal, parce que je dois reconnaître avoir plus d'un problème avec GDB, et quand on voit la différence entre clang et g++, je suis assez impatient de voir ce que donnerait un débogueur fait par les mêmes que clang: je suis passé à clang récemment, et je ne pense même plus à pousser la ram de mon netbook au delà de 1Go, avant, je devais compiler mon projet avec 2 processus pour éviter de ramer comme un porc pendant 5 à 10 minutes, maintenant, 4 processus passent, et je peux utiliser les 4 threads de mon processeur ! J'aime beaucoup.

D'ailleurs, quelqu'un connaît un frontend style cgdb, ddd ou autre pour ce fameux débogueur?

Vivement que ça sorte dans Debian (unstable, bien sûr, pour la stable, faut attendre 2 ans minimum ^^ ), cette version 3.2 ...

[PsychoH13]

Si « low-level debugger LLDB » est intégré, cela veut dire qu'on pourra utiliser autre chose que GDB pour déboguer dans quelques temps?

Ce serait pas mal, parce que je dois reconnaître avoir plus d'un problème avec GDB, et quand on voit la différence entre clang et g++, je suis assez impatient de voir ce que donnerait un débogueur fait par les mêmes que clang: je suis passé à clang récemment, et je ne pense même plus à pousser la ram de mon netbook au delà de 1Go, avant, je devais compiler mon projet avec 2 processus pour éviter de ramer comme un porc pendant 5 à 10 minutes, maintenant, 4 processus passent, et je peux utiliser les 4 threads de mon processeur ! J'aime beaucoup.

D'ailleurs, quelqu'un connaît un frontend style cgdb, ddd ou autre pour ce fameux débogueur?

Vivement que ça sorte dans Debian (unstable, bien sûr, pour la stable, faut attendre 2 ans minimum ^^ ), cette version 3.2 ...

Sur Mac, on utilise déjà exclusivement LLDB au lieu de GDB, donc je pense pas que tu aies besoin d'attendre longtemps.

[Klaim]

Sur Mac, on utilise déjà exclusivement LLDB au lieu de GDB, donc je pense pas que tu aies besoin d'attendre longtemps.

Attention, les numeros de version de la version fournie par Apple ne correponds pas du tout aux releases officielles de LLVM. Ils ont leur propre version modifiee et avec leur propre numero de version.

[Freem]

Sur Mac, on utilise déjà exclusivement LLDB au lieu de GDB, donc je pense pas que tu aies besoin d'attendre longtemps.

Effectivement. Aurais-tu quelques retours dessus, ou mieux, des outils l'utilisant?

Parce que, très sincèrement, GDB est une plaie pour moi. A moins que ce ne soient les interfaces qui j'y ai trouvé (code::blocks et cgdb) qui en soient la cause, mais il est juste incapable de déboguer le projet sur lequel je travaille actuellement.
Au point que je suis contraint d'utiliser des horreurs type printf("%s\t%d\n",__FILE__, __LINE__); pour savoir ou ça plante...

Je soupçonne le multi-thread interne à wxwidgets d'être la cause de mes problèmes, mais peu importe, quand le débogueur n'est pas capable d'arrêter le programme quand on lui demande avec un breakpoint, ce n'est pas la faute de la bibliothèque!

Donc, si quelqu'un à des pistes...

[Klaim]

Sur mac jusqu'a present je crois que c'est GDB par defaut...


Sinon, il me semble avoir lu soit sur la mailing list, soit sur le site de LLVM que le nouveau debugger est maintenant corrige et donc carement superieur a GDB, mais quand j'ai lu ce poste j'ai cherche ou j'ai lu ca et je ne retrouve plus ma source.

Tu ferais mieu de demander sur la mailing list a mon avis.