写这篇博文，是因为最近某上海惠普Open64编译部门师兄来实验室搞了个小座谈(惠普在中国准备扩大编译团队，有感兴趣的，别错过机会).期间，我就问了关于LLVM的问题，Open64社区如何看待可能来自LLVM的威胁。以下内容，是我自己的记录和演绎版本，本人不保证完全是原话和原意，请各位酌情理解：）
师兄先举了几个例子。他前天在清华和别人聊的时候，也聊到这个问题，虽然LLVM很活跃，但毕竟很年轻。虽然概念很好(前瞻-全时优化和LLVM-2 前瞻-全时优化和LLVM-1)，但实施起来很难。就目前LLVM所做的工作来说(前瞻-LLVM大事记(2004-2010) )，大部分只是在重复Open64十几年前所做的。其实SSA的思想最早也是来自Open64.之后才开始在GCC，LLVM中有涉及。 Google内部也曾经争论过是否应该推LLVM，曾经争论很大，但最终还是没有推。当时支持LLVM的人，大多是对编译不太了解的人，而反对的，则是在编译上有很多经验的人。
之所以现在这么热，我个人的观点是，LLVM提出了一种新的中间表示，并在该中间表示上做优化。能够暴露很多可研究的点。增加很多的新特性。从2005年LLVM正式成为一个工业级编译器开发，到现在，LLVM才刚刚完成了健壮性的保证(自编译),一个编译器，针对某个应用的bug调试和优化不难，难的是对所有的程序平均性能都好。最近的C++0x标准支持开发，新的debuger开发，都才刚刚开始，还有很长的路要走。
另一方面，GCC虽然很繁杂，但现在的架构也在慢慢的走向清晰化和合理化，加入了很多优化。而且有了插件支持。这些都让LLVM的竞争力小了很多。
和LLVM相比，Open64的健壮性和兼容性，已经经过了时间的考验，虽然现在还有bug。现在有AMD和HP两家公司的优化和支持。Open64一直觉得LLVM还是个玩具，一个科研用的编译器。产品化的道路还很长。
另外，开了眼界，一个大服务器都卖到几百上千万。大服务器的销售人员做一个单子都够吃几年的。相比于个人计算机，大型服务器的利润率更高。惠普在X86服务器方面，是业界老大。惠普的内部架构分为三块，服务器、个人电脑和打印机。惠普编译器部门分两个方向，Open64和aCC，前者主要用在X86芯片的优化上。后者主要针对安腾服务器。惠普也使用Vtunes来找优化机会，Open64的性能是要和ICC PK的。这位师兄对Open64的未来，以及惠普编译团队的前景都充满信心。整个座谈在友好和谐的气氛中进行。师兄根据惠普编译组的工作情况，热情洋溢，信心十足，实事求是，而又平易近人的回答了师弟师妹们的问题。
也预祝Open64和惠普编译团队越来越好。
PS：这篇文章的内容可能因为作者和惠普那位师兄从事Open64编译器的工作而存在一定的主观倾向，请参考下面评论中读者Aunt P的评论。
来这才听说open64，一般用gcc
@baozii, :-)，Open64也比较好用。因为前端用的GCC，所以报警和源代码的语法报错都和GCC一样。Open64一般针对X86做优化，而且编译器本身的bug也比GCC稍多一些，所以用的人不多。主要还是看重编译优化，搞编译器的人才知道
确实很需要一个中立的专业人士，把他的判断和好的品位，介绍给不明真相的群众。
博主努力。
另外不是说 google 在整 Native Client+LLVM 吗？怎么又说 google 不推 LLVM。
@ayaya, 谢谢鼓励，呵呵。我一定再接再厉！Google不推LLVM，应该是针对整个公司内部的工具链标准上。即，全公司的开发和应用，还是不能基于LLVM做。因为Google内部鼓励员工参与开源项目。且Google现在也只在Native Client和 Unladden Swallow上有用LLVM，也不是再推LLVM，我怀疑可能是Google内部的人，想尝试这么使用LLVM。
llvm 的全时优化还不是很明白呢，尤其是空闲时和安装时…
@baozii, 程序在运行的过程中，是有具体的行为的。比如分支的执行规律，用户喜欢使用程序的那一部分的功能。等等。这些都可以在程序执行过程中收集。收集到的这些信息就可以用来指导优化，空闲时的优化就是用这些信息来指导优化。
因为不同的芯片有自己独特的性能。比如SIMD方面，intel的CPU有SSE，AVX。AMD的CPU有3DNow!.这样，在源代码编译成具体可执行程序时，可以编译针对不同CPU，不同优化的程序。这样在安装的时候，可以根据用户的CPU不同，安装相应的优化代码。
什么软件领域的开发用Open64比较多？
@myesis, 算法固定，计算时间敏感的高性能计算领域。比如流体力学，蛋白质折叠，还有其他的科学计算。看看pathscale的官方网站，和Hp的x86服务器卖给谁，就知道了。呵呵
cool~ 如此说来 c/c++ 或许也是以llvm中间码的形态保存着，然后用到了jit之类的技术吧。
我发现自己真的还是懂得太少…你说的空闲时我一直以为是运行时优化，其实真正的运行时优化又是什么呢？
@baozii, 呵呵，术业有专攻而已，你懂得，我说不定也不明白。 运行时优化，因为有了运行时的环境和程序运行的历史行为，可以让某些优化做的更确定，更激进。比如内联优化(inline),仅仅静态优化时，需要插入断言代码来确定程序是否能运行内联部分的代码，而在运行时，因为已经确定是否满足条件，就能直接决定是否内联，并将符合条件的代码插入到即将翻译成机器码的代码中去。在比如分支跳转，在运行时跳转的更加可靠。循环展开在运行时如何展开也能知道的很确定。
我还是觉得LLVM的IR层级太少了……要说各种分析优化设施完备还是Open64。
@nightfire, 同意，关键是怎么把Open64里面的IR层次用起来，感觉现在WHIRL的潜力完全没有发挥出来。
@erlv, 其实可以做这个个研究哈，把后面几个级别的WHIRL弄出来，做虚拟机执行，看哪一级WHIRL是理想的编译器优化与运行时优化的分界线。
@nightfire, 这个，我只能说佩服佩服，一篇文章的idea就这么来了：）这种文章如果做出来，至少也得是个CGO
再稍微增加点改进什么的就能再上一个新台阶了。毕竟是中间表示上的革命。
关键是没人支持。Open64的每个优化都太封闭了，如果能把Open64 WOPT阶段的SSA打开，像GCC和LLVM那样直接从
SSA生成汇编，估计能省掉不少功夫(当然CG阶段基于流图的优化和寄存器分配什么的也得找个阶段实现)
咱可以先做优化少点的缩水版的……不然又弄编译器又做vm得弄到哪年去……发了文章以后说不定有兴趣的人还能多点。不过就算缩水code work应该还是不少，你想做这样规模的实验得忽悠Mr.Feng给你配俩师弟打下手 XD
@nightfire, 做完我的硕士论文，有机会的话，可以动手试试。呵呵。很不错的想法。Mr. Feng估计会想，小样，要想按时毕业，你还是赶快先写你的硕士论文吧！
那么做全时优化是不是一定要做层级较低的中间语言呢？jvm和llvm相比有啥区别，是上层支持更多的语言特性嘛？
@baozii,
1，做全时优化，层次确实不能太高。但不代表一定得非常低，我个人更倾向于使用JVM做优化。我觉得LLVM之所以想把中间表示做低，是想做个能支持尽可能多高级语言的虚拟机，想看看再稍低点的中间表示会有多少机会，因为JVM已经做了较高层的，所以LLVM没有必要重复JVM的工作。
2， JVM和LLVM相比，中间表示更高一些。bytecode支持栈操作，例外，并发支持，对象的创建和维护等高级特性。而LLVM仅仅支持类似RISC的指令。
还是八卦类的东西广大人民群众参与度的热情高呵。
@ayaya, 呵呵，毕竟很多都不是搞Open64的。八卦最不需要相关技术基础。为人民群众喜闻乐见：）
坤哥，我求你了，删了这个乱评论的文章吧。
1，iPhone SDK里面是compiler是LLVM-GCC而不是Open64，到底谁经过的考验少啊？2，Open64那个鸟玩意儿能自举么？Clang可以！
3，Open64有自己的FE么？Open64敢保证以后不用Clang做FE么？
我已经花时间在Whirl上面了，也发现了Whirl比LLVM优秀的地方，我现在正在做Clang的完善，以后还会把Whirl优秀的地方实现在LLVM上（就那么两个点而已），时间也是检验真理的唯二标准。
PathScale作为vendor，恐怕你们没有主导权吧？人家的代码结构还是比你们的清晰不少。
1吨的bug，慢慢玩儿吧。至少我们的bug还不到1千克。
抱歉，这篇文章让你觉得有点乱谈，可能是因为你的工作基于LLVM，而我在Open64上做过些东西.呵呵，所以各自都不太了解另外一个编译架构。但是不该因此就删除这篇文章。我已经修改了原文，提醒读者读这篇文章时考虑作者可能存在的偏见。
1，你谈了很多关于编译器通用型的问题，一方面LLVM是苹果做的，所以他支持苹果的操作系统和平台是很正常的。就像你在惠普的服务器上用Open64问题也不大一样.基于X86平台的Open64肯定能自举，这个你可以去Open64的mail list里问。
2，Open64没有自己的FE，Open64的侧重是强大的后端优化，即LNO，WOPT和CG的优化，其实用什么前端都无所谓。
能否具体介绍一下你认为Whril比LLVM优秀的两个点？我对LLVM不了解：）
Pathscale和Open64的关系不是一时半会能说清楚的.Open64的bug没那么多，你可以去Open64的bugzilla上看看.
PS：Open64是个传统意义上的高性能优化编译器.注重优化。LLVM的侧重点应该是在运行时环境吧，请你介绍介绍。所以单纯的比较，应该看两个编译器是否都达到了各自的目的。