John Siracusa

LLVM et Clang

Apple a fait un investissement stratégique dans le projet open source LLVM il y a plusieurs années déjà. J'ai abordé les fondamentaux de LLVM dans mon compte-rendu de Léopard. (Si vous n'êtes pas au courant, mettez vous à la page avant de continuer). J'y ai montré comment Léopard utilisait LLVM pour fournir une implémentation logicielle compilée à la volée (JIT), des fonctions OpenCL en les rendant considérablement plus efficaces.

Ne soyez pas abusé(e) par son usage limité sous Léopard ; Apple a des plans ambitieux pour LLVM. Jusqu'où ? Pourquoi ne pas remplacer les boyaux du compilateur gcc que Mac OS X utilise actuellement, par ceux équivalents de LLVM ? Ce projet est bien lancé. Pas assez ambitieux ? Pourquoi ne pas s'affranchir entièrement de gcc et le remplacer par un nouveau compilateur, basé sur LLVM (mais compatible avec gcc) ? Ce projet s'appelle Clang et il déjà fourni quelques résultats de performance impressionnante.

Avec l'introduction de Léopard des neiges, c'est officiel : Clang et LLVM représentent la stratégie adoptée par Apple. LLVM a un nouveau logo stylé, un hommage appuyé à un manuel bien connu de conception des compilateurs.

Le dragon

LLVM! Clang!

Apple fournit maintenant pas moins de 4 compilateurs pour Mac OS X : GCC 4.0, GCC 4.2, LLVM-GCC 4.2 (GCC 4.2 en accès direct, et LLVM dans les coulisses), et Clang, pour améliorer la migration vers LLVM. En voici un croquis :

Compilateurs

Les compilateurs Mac OS X

Tous ces compilateurs ont un binaire compatible sous Mac OS X, si bien que vous pouvez par exemple, construire une bibliothèque avec un compilateur, et la lier à un exécutable construit avec un autre compilateur. Ils sont aussi -en théorie au moins- tous compatibles pour les sources et les commandes. Clang ne supporte pas encore quelques caractéristiques ésotériques de GCC, et il ne supporte aussi que C, Objective C, un peu de C++ (Clang(age) ; vous avez compris ?), alors que GCC en supporte beaucoup plus. Apple se consacre au support complet de C++ pour Clang, et espère éliminer les incompatibilités qui subsistent avec GCC pendant la durée de vie de Léopard des neiges.

Clang apporte deux attributs importants que vous êtes en droit d'attendre d'un nouveau compilateur au goût du jour : des délais de compilation plus courts, et des exécutables plus rapides. Selon les tests d'Apple avec ses propres applications, comme iCal, Address Book ou même XCode, et des applications tierces comme Adium ou Growl, Clang compile à peu près trois fois plus vite que GCC 4.2. Quant à la vitesse du produit fini, LLVM en arrière plan, que ce soit dans Clang ou dans LLVM_GCC, produit des exécutables qui sont 5 à 25 % plus rapides que ceux créés par GCC 4.2.

Clang est aussi plus facile pour les développeurs que ses prédécesseurs GCC. J'admet que cela n'a pas grand chose à voir avec l'avantage d'utiliser des CPU à plusieurs cœurs, ou des choses de ce genre, mais il est sûr que c'est une des premières choses qu'un développeur remarque effectivement. Permettez-moi de m'en réjouir.

Pour les débutants, Clang est encapsulable, si bien que XCode peut utiliser la même infrastructure de compilateur pour les possibilités de l'IDE (recherche par symbole, complétion de code) que celle qu'il utilise pour compiler le code final exécutable. Clang crée et conserve aussi des méta-data beaucoup plus étendues pendant la compilation, ce qui permet un bien meilleur rapport d'erreur. Par exemple, quand GCC vous dit ceci : Clang
Ce n'est pas très clair de savoir où est le problème, particulièrement si vous débutez en C. Bien sûr, vous les experts, vous savez déjà où il est (et notamment si vous avez déjà vu ces exemple à la WWDC) mais je crois que tout le monde sera d'accord pour admettre que ce message d'erreur généré par Clang et bien plus utile : Clang
Peut-être qu'un novice ne saura pas encore quoi faire, mais au moins on sait clairement où est le problème. Imaginer pourquoi le compilateur ne connaît pas NSString est une tâche bien plus ciblée que ce que le message d'erreur obscur de GCC permet de déduire.

Même quand le message est clair, le contexte peut ne pas l'être. Voyez cette erreur de GCC : Clang
Il y a bien quatre opérateurs "+" sur cette ligne. Lequel a des opérandes qui posent problème ? Grâce à ses méta-data plus détaillées, Clang peut mieux le localiser : Clang

Parfois, l'erreur est parfaitement claire, mais elle semble seulement un peu décalée, comme dans cette situation où GCC positionne le message d'erreur à la ligne en-dessous celle où vous devez rajouter le ; manquant. Clang
Ces petites chose là comptent, vous savez ? Clang fait mieux : Clang

Que vous le croyiez ou non, ces petites choses ont beaucoup d'importance pour les développeurs. Et puis, il y a ces choses pas si petites, qui comptent encore plus, comme l'analyseur statique fourni par LLVM. L'image qui suit montre comment il affiche sa découverte comme une bogue possible. Clang

Au delà de la fantaisie des petites flèches (qui, admettez-le, sont adorables) la bogue qu'elles soulignent est quelque chose que tout programmeur peut arriver à faire (pour peu qu'il écrive un peu vite). L'analyseur statique est arrivé à la conclusion qu'il y a au moins un chemin par lequel on ne passe pas dans ces conditions imbriquées, et qui laisse la variable myName non initialisée, ce qui rend potentiellement dangereuse la tentative de lui envoyer le message mutableCopy, sur la dernière ligne.

Je suis sûr qu'Apple doit être très friand de l'analyseur statique pour toutes ses applications, et le système d'exploitation lui-même. La recherche d'une méthode automatique pour découvrir les bogues qui peuvent exister depuis des années dans les entrailles d'une base de code gigantesque est presque un sujet pornographique pour les développeurs - en particulier ceux qui proposent des systèmes d'exploitation. Dans la mesure où Mac OS X 10.6 a moins de bogues que les versions précédentes (10.x.0), LLVM y a sûrement une part significative.

Le maître du logis

En s'engageant dans la voie du couple puissant Clang-LLVM, Apple a finalement pris le contrôle complet de son système de développement. L'expérience de Code Warrior a finalement convaincu Apple qu'il n'était pas avisé de s'appuyer sur un tiers pour les outils de sa plate-forme de développement. Bien que cela ait pris de nombreuses années, je pense que le plus inconditionnel des fans de Metrowerks devrait admettre que XCode, dans Léopard des neiges est un IDE sacrément bon.

Après des années de bataille à cause de la différence entre les objectifs du projet GCC et ses propres besoins en compilateur, Apple a finalement coupé le cordon. Bien sûr, c'est vrai, GCC 4.2 est encore le compilateur par défaut dans Léopard des neiges, Mais c'est une phase de transition. Clang est le compilateur recommandé, et le point de mire de tous les efforts futurs d'Apple.

Je sais ce que vous pensez. C'est de l'enflure, et tout... Comment ces compilateurs peuvent-ils aider les développeurs à démultiplier la puissance des myriades de transistors mise à leur disposition ? Comme vous allez le voir dans les sections qui suivent, la tête écailleuse et métallique de LLVM se pointe à quelques endroits clé.