URL: https://linuxfr.org/news/llvm-3-4-et-clang-3-4 Title: LLVM 3.4 et Clang 3.4 Authors: Sylvestre Ledru rewind, Yves Bourguignon, Benoît Sibaud, claudex, Xavier Teyssier, Florent Zara et Nÿco Date: 2013年12月03日T11:59:34+01:00 License: CC By-SA Tags: lwn, objective-c et debian Score: 52 A-t-on encore besoin de présenter [LLVM](http://llvm.org/) et [Clang](http://clang.llvm.org/) ? Cette suite de compilation est désormais bien établie, en particulier dans le monde du logiciel libre où elle est utilisée dans de nombreux projets ([Emscripten](http://emscripten.org/), [llvmpipe](http://www.mesa3d.org/llvmpipe.html), entre autres). L'application la plus en vue associée à LLVM est sans aucun doute Clang, le compilateur C/C++/ObjectiveC officiel du projet. [Le 6 janvier dernier sont sorties les versions 3.4 de LLVM et de Clang](http://lwn.net/Articles/579408/). Les nouveautés sont détaillées dans la suite de la dépêche. ---- [LLVM 3.4 Release Notes](http://llvm.org/releases/3.4/docs/ReleaseNotes.html) [Clang 3.4 Release Notes](http://llvm.org/releases/3.4/tools/clang/docs/ReleaseNotes.html) [LLVM 3.3 et Clang 3.3](http://linuxfr.org/news/llvm-3-3-et-clang-3-3) ---- Que ce soit pour LLVM 3.4 ou Clang 3.4, ce sont les dernières versions qui utiliseront C++98. Progressivement, ces deux projets vont utiliser des fonctionnalités de C++11. Cette décision a donné lieu à [une très longue discussion sur la liste de diffusion](http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-October/066847.html), notamment pour permettre une migration des [chaînes de compilation](http://fr.wikipedia.org/wiki/Cha%C3%AEne_de_compilation) utilisées ça et là pour compiler LLVM. Maintenant, une discussion commence pour savoir quels compilateurs seront ciblés et donc quelles fonctionnalités de C++11 pourront être utilisées. L'ensemble de départ comprend Visual Studio 2012, Clang 3.1 et GCC 4.7. # LLVM 3.4 ## Passes d'optimisation La [passe de simplification d'appel de bibliothèque](http://llvm.org/docs/Passes.html#simplify-libcalls-simplify-well-known-library-calls) (qui permet par exemple de transformer un `exit(3)` en `return 3` quand il est appelé dans `main`), a été supprimée en tant que telle. Ses fonctionnalités sont maintenant intégrées dans d'autres passes d'optimisation. La [vectorisation des boucles](http://llvm.org/docs/Vectorizers.html#the-loop-vectorizer), qui déroule certaines boucles `for`, est maintenant activée pour `-Os` et `-O2`, plutôt que `-O3` précédemment. La [vectorisation SLP](http://llvm.org/docs/Vectorizers.html#the-slp-vectorizer), qui transforme des groupes d'instructions simples en instructions vectorielles, est également activée par défaut. ## Architectures La gestion de l'architecture R600 présente dans les cartes graphiques AMD n'est plus considérée comme expérimentale. On peut également noter des améliorations générales concernant la prise en charge des architectures GPU. La gestion des espaces d'adressage existe depuis longtemps dans LLVM mais n'était pas vraiment utilisée jusqu'à récemment. Avec l'arrivée du GPGPU, il est devenu nécessaire de bien faire la différence entre les espaces d'adressage (celui de la RAM et celui de la carte graphique) et donc les compilateurs doivent gérer ces espaces d'adressage de la bonne manière. Dans LLVM 3.4, il n'est plus possible de réaliser un `bitcast` entre des pointeurs de différents espaces d'adressage, il faut désormais utiliser la [nouvelle instruction `addrspacecast`](http://llvm.org/docs/LangRef.html#addrspacecast-to-instruction). De plus, les pointeurs de différents espaces d'adressage peuvent désormais être de taille différente. La gestion de l'architecture PowerPC a vu de nombreuses améliorations dans la qualité du code produit, notamment un meilleur ordonnancement des instructions pour les cœurs embarqués, une meilleure génération des prologues et épilogues, la génération d'instructions particulières ou vectorielles. La gestion de l'architecture Sparc a permis de grosses améliorations sur de nombreux points importants : la gestion des flottants 128 bits, la gestion des exceptions, la gestion de la [mémoire locale à un thread](http://fr.wikipedia.org/wiki/Thread_Local_Storage). En plus, l'architecture Sparc V9 (64 bits) est gérée de manière expérimentale, et la compilation JIT est désormais prise en charge. ## Autres améliorations Le [binding](http://fr.wikipedia.org/wiki/Binding) OCaml de LLVM est maintenant plus complet et couvre l'ensemble des bibliothèques LLVM. # Clang 3.4 ## Meilleurs diagnostics Clang est connu depuis le début pour offrir de très bons diagnostics, ce qui a poussé GCC a rattraper son retard. Mais Clang n'en reste pas moins actif pour autant. Et cette version 3.4 est l'occasion d'apporter de nouveaux diagnostics. Parmi [tous ceux qui ont été ajoutés](http://llvm.org/releases/3.4/tools/clang/docs/ReleaseNotes.html#improvements-to-clang-s-diagnostics), on peut retenir : `-Wheader-guard` prévient si les noms utilisés ne correspondent pas : ```cpp #ifndef multiple #define multi #endif ``` renverra : `warning: ‘multiple’ is used as a header guard here, followed by #define of a different macro [-Wheader-guard]` `-Wloop-analysis` prévient si la variable de boucle est incrémentée à l'intérieur de la boucle. ```cpp void foo(char *a, char *b, unsigned c) { for (unsigned i = 0; i < c; ++i) { a[i] = b[i]; ++i; } } ``` renverra : `warning: variable ‘i’ is incremented both in the loop header and in the loop body [-Wloop-analysis]` En plus, des propositions de correction ont été ajoutées dans beaucoup de cas, comme quand `->` a été utilisé à la place de `.` et vice-versa, ou pour des noms de fonctions/méthodes proches avec un nombre de paramètres différent. ## Options de compilation L'[optimisation à la liaison](http://en.wikipedia.org/wiki/Link-time_optimization) n'est plus déclenché avec `-O4` mais avec `-flto`, ce qui permet de l'utiliser pour n'importe quel niveau d'optimisation. [Sylvestre Ledru](http://linuxfr.org/users/grayswandir) sera ravi d'apprendre qu'il va supprimer [49 erreurs](http://clang.debian.net/status.php?version=3.3&key=WRONG_OPTIM_VAL) dans la [recompilation de l’archive Debian avec Clang](http://clang.debian.net/), puisque l'option `-O` ne provoquera plus d'erreur si le niveau d'optimisation demandé est supérieur à 5. Dans tous ces cas, cela sera considéré comme un `-O3`. Malheureusement pour lui, le compilateur provoquera des erreurs avec des options non-connues, ce qui risque d'augmenter le nombre d'erreurs, pour les projets qui utilisent des options spécifiques à GCC (mais les différences entre Clang et GCC sont peu nombreuses). ## Amélioration de C++ ### C++1y La [prise en charge de la prochaine version de C++](http://clang.llvm.org/cxx_status.html#cxx14), actuellement baptisée C++1y (puisque C++1x est devenu C++11) et qui sera probablement [C++14](http://fr.wikipedia.org/wiki/C%2B%2B14), se poursuit au rythme des décisions du comité de normalisation. Pour rappel, C++14 sera une mise à jour mineure de C++11, pour corriger les erreurs de C++11, préciser certaines parties de la spécification, et compléter quelques oublis. Il y aura quelques nouveautés, notamment dans la bibliothèque standard mais pas aussi importantes que pour C++11 par rapport à C++03. Les vrais nouveautés (comme `` ou ``) apparaîtront sans doute avec C++17. ### `libunwind` LLVM propose désormais [sa propre version de `libunwind`](http://blog.llvm.org/2013/10/new-libunwind-implementation-in-libcabi.html). Cette bibliothèque est utile pour les systèmes qui ne peuvent pas gérer les exceptions nativement. Ceci complète [la série de bibliothèques nécessaires pour l'exécution de programmes C++](http://libcxxabi.llvm.org/). ## Statut d'OpenMP [OpenMP arrive petit à petit dans Clang](http://blog.llvm.org/2013/10/openmp-project.html). Intel a offert au projet la partie exécution d'OpenMP (l'équivalent de la [`libgomp`](http://gcc.gnu.org/projects/gomp/) pour GCC). L'[objectif annoncé](http://openmp.llvm.org/) est d'être compatible binairement avec GCC et icc, ce qui est une très bonne nouvelle. La gestion complète d'OpenMP (3.1 et 4) devrait arriver dans les prochaines versions de Clang. ## Pilote de compilation pour Windows Clang propose désormais [un pilote de compilation pour Windows](http://blog.llvm.org/2013/09/a-path-forward-for-llvm-toolchain-on.html). Le but est à terme de pouvoir [remplacer le pilote de compilation de Visual Studio](http://blog.llvm.org/2013/11/the-clang-cl-fallback-mode.html) directement et donc de fournir les mêmes options (des trucs avec des `/` au lieu de `-` et des noms [cryptiques](http://fr.wiktionary.org/wiki/cryptique)). Il existe un buildbot qui construit des [versions](http://llvm.org/builds/) régulièrement même si elles sont encore considérées comme expérimentales.

AltStyle によって変換されたページ (->オリジナル) /