LLVM 与 Clang 介绍

转自：http://www.feng.com/apple/blog/2009-09-27/The_heart_of_Snow_Leopard_LLVM_and_Clang_206356.shtml

http://www.itshequ.com/2010/02-09/8314.html

  早在几年以前，Apple就在LLVM开源计划上做出了重要的战略性投资。我曾在一篇介绍Mac OS X Leopard的文章中简要介绍了LLVM的一些基本情况，Leopard利用LLVM技术为JIT编译软件的OpenGL功能提供了高效的执行支持。在那篇综述的最后，我这样结尾：对于LLVM，Apple拥有相当宏伟的计划：逐步摒弃Mac OS X中现有的GCC编译器集合(complier collection)，并采用全新的基于LLVM的编译器系统。该计划称为"Clang"，并且已有了一些可喜的进展。        

 

      随着Snow Leopard的推出，这一切开始逐渐浮出水面：Clang和LLVM已成为Apple现行的编译策略。LLVM甚至还有一个全新的帅气的标志：

 

      目前，Apple为Mac OS X总共提供了四种编译器：GCC 4.0，GCC4.2，LLVM-GCC 4.2，以及Clang。这里是一个图表：

 

      所有这些编译器在Mac OS X上均具有二进制兼容性(binary-compatible)，这就意味着您可以使用一种编译器创建一个资源库并与使用另一个编译器创建的可执行文件相链接。并且，理论上讲，这些都是命令行编辑器并且都具有资源兼容性。然而，Clang目前暂不支持GCC的一些复杂功能，同时Clang只支持C、Objective-C和一点点C++(而GCC支持的相对较多)。Apple承诺，Clang未来将会为C++提供全方位支持，并且希望能够在Snow Leopard的“服役期间”内解决GCC的不兼容问题。

      Apple为Clang带来了两条引人注目的特性，那就是：更短的编译时间和更快的可执行文件。Apple用其自身的软件如iCal，Address Book，Xcode，以及一些第三方软件如Adium和Growl进行了测试，Clang编译器比GCC4.2快了近乎3倍。而对于编译的可执行文件运行速度，由Clang生成的可执行文件则比GCC 4.2生成的可执行文件快5~25%。

      同时，与其前任GCC相比，Clang提供了更为友好的开发环境。我承认这和多核CPU等新技术的优势并无很大关联，但这确实开发者在使用Clang时首先面对的。

      对于新手来说，Clang具有可嵌入性，因此Xcode可以在IDE的一些交互功能中使用和最终的可执行文件相同的编译器结构。在编译过程中，Clang创建并保留了大量详细的元数据(metadata)，从而有利于调试和错误报告。例如，如果GCC返回如下错误：

 

      这时候很难说清问题究竟在哪，对于编程新手来说尤为如此。好吧，牛人或许已经看出来问题在哪了(如果您在WWDC上看到了这个例子的话)，但是我相信大家都会认为Clang返回的错误报告更有用：

 

       可能个别菜鸟仍然不知所措，但是至少可以清晰地看到问题究竟出在哪里了：与GCC含糊其辞的回应相比，Clang明明白白告诉你，哥们儿我不认识“NSString”这个类型… 

       而且，有时候即使错误信息很明确，具体细节却未必如此，譬如GCC返回的这个错误提示：

 

      很明显，“无效的运算符号+”，但是这条语句中有4个“+”，究竟哪一个有问题呢？多亏这些相近的元数据(metadata)，Clang可以明确地为您指出问题所在：

 

      更进一步抬杠。有时候错误一目了然，譬如这个GCC的例子，在报错行以上的语句中丢失了一个分号“；”：

 

      而Clang则更进一步，指出了究竟哪里丢失了这个分号：

 

      楼下同学说了，这些都是“小事儿”，完全是鸡蛋里头挑骨头没事儿找事儿，然而对于程序员来说，Clang提供的这种更为细致和细心的提示是相当贴心的。当然，还有一些细节对于程序员来说则意义重大了，譬如这个基于LLVM的静态分析器(static analyzer)。下图显示了静态分析器发现并指出了一处可能的bug：

 

      图中高亮的部分明确地指出了任何一位程序员都有可能犯的bug。静态分析器检测到，这一系列嵌套条件中，“myName”变量在至少一条路径里中未被初始化，从而使得在最后一行发送“mutableCopy”时存在潜在的危险。

      我相信Apple一定在其所有应用程序和操作系统上运行过静态分析器，以检查一些潜在的bug。而对程序员来说，能够在庞大的代码库中自动监测潜在的bug，无疑是一件非常爽的事情，对于自己开发平台的程序员来说更是如此。某种程度上来讲，Mac OS X 10.6.0中存在的bug比先前的任何一个10.x.0系统的bug都要少，无疑这将归功于LLVM。

      通过Clang/LLVM的进一步推广和完善，Apple终于能够完全掌控其自己的开发平台了。CodeWarrior的经验显然使Apple更加清晰地认识到，依赖于第三方平台开发工具是相当不明智的。尽管花费了许多年的时间，但我认为即使最顽固的Metrowerks支持者也会认为，Snow Leopard提供的Xcode确实是个相当不错的IDE。

      许多年以来Apple一直纠结于GCC计划与Apple自身的编译需求之间的脱节，现在Apple终于痛下决心另辟蹊径。诚然，GCC 4.2仍然是Snow Leopard的默认编译器，但是很显然Apple已进入的过渡期。Clang自然是推荐的编译器，并且在可预见的将来，Apple的焦点将集中于此。

      上期连载中已经提到，硬件领域的技术进步已经使得软件和操作系统成为了目前限制计算机性能的主要因素。或许您会有一些疑惑，究竟这些编译器将如何帮助开发者更好地利用现有的硬件资源呢？下期连载将为您分析这个问题。