您可能也喜欢：

webkit-龙小组成立

WebKit和Firefox的JavaScript性能对比

龙芯N32系统上的Squirrelfish性能

GNOME 2.22 抢先预览

JAVA虚拟机入门

无觅

相关文章：

• AMD intern and full time compiler position based on OpenCL and LLVM
• MNC need compiler expert
• 美国国家仪器（NI）招聘信息
• 能给H1B签证的编译器及模拟器职位–Compilers jobs at Tensilica
• Pathscale招聘Fortran编译器背景工程师
• AMD招聘Open64编译器开发工程师–北美

1. webkit-龙移植优化小组成立，dancefish和philip兄加入。dancefish兄对webkit在嵌入式系统上的移植和裁剪经验丰富，philip兄对webkit在andorid系统下的编译调试也有丰富经验。几番邮件交流之后,根据个人的兴趣爱好和实际工作，大致分了一下，dancefish和philip侧重webkit中的webcore部分，以及浏览器的验证。我将侧重JavaScript部分的JIT。这个分工只是大致而已。大家都是凭自己的热心兴趣在做。
2. webkit的现状：gentoo emerge的 webkit-qt,webkit-gtk现在能编译，运行能弹出浏览器框，但经常bus error崩溃。怀疑和这个bug有关。
3. 机器问题:dancefish有机器，philip兄的机器，下周联系一下龙梦，看能否再给邮寄一台。
4. 感谢zsc顾问提供的建议，解决了关于date的bug，现在squirrelfish的解释器只剩下一个 bug  ecma/Math/15.8.2.17.js.
5. 感谢lei兄的建议，但最近从webkit svn库同步代码之后，我的龙芯小本在最后ld ../lib/libQtWebKit.so.4.8.0时报错final link failed:Bad value.所以没能尝试你的建议。 而且这个ld除了报fail link外再也没有其他任何错误提示。跟踪了一下内存使用情况，物理内存耗尽了，swap分区是开着的，但ld好像并没有使用swap分区。估计是因为这个原因导致的出错。
6. 创建了webkit-ls的git 代码库。  http://gitorious.org/webkit-ls

您可能也喜欢：

龙芯N32系统上的Squirrelfish性能

GCC即将支持龙芯3A

JIT Compiler and Virtual Machine SW Engineer for Web Browsers in Qualcomm

关于龙芯公司的小道消息

龙芯中科公司招聘JAVA虚拟机开发工程师

无觅

相关文章：

• 龙芯N32系统上的Squirrelfish性能
• WebKit和Firefox的JavaScript性能对比
• 宏和内联函数
• 拥有Nanojit龙芯后端的firefox发布(10年1月14日更新)
• 使用crossdev安装龙芯的O32 gnu交叉工具链
• JIT Compiler and Virtual Machine SW Engineer for Web Browsers in Qualcomm

Squirrelfish 是Webkit的Javascript引擎。针对龙芯平台(MIPS)已经有了JIT支持，但仅仅对O32系统才有，本博曾经介绍过相关内容（WebKit和Firefox的JavaScript性能对比）。

切入正题，N32系统下，龙芯平台上，Sunspider性能测试结果如下：

============================================
RESULTS (means and 95% confidence intervals)
--------------------------------------------
Total: 9125.6ms +/- 0.1%
--------------------------------------------
3d: 1058.6ms +/- 0.2%
cube: 326.9ms +/- 0.1%
morph: 380.9ms +/- 0.6%
raytrace: 350.8ms +/- 0.1%
access: 1441.2ms +/- 0.1%
binary-trees: 108.4ms +/- 0.3%
fannkuch: 829.2ms +/- 0.2%
nbody: 249.0ms +/- 0.0%
nsieve: 254.6ms +/- 0.4%
bitops: 1088.6ms +/- 0.2%
3bit-bits-in-byte: 196.2ms +/- 0.3%
bits-in-byte: 250.1ms +/- 0.2%
bitwise-and: 224.9ms +/- 0.3%
nsieve-bits: 417.4ms +/- 0.3%
controlflow: 138.2ms +/- 0.2%
recursive: 138.2ms +/- 0.2%
crypto: 621.5ms +/- 0.1%
aes: 323.0ms +/- 0.1%
md5: 145.3ms +/- 0.2%
sha1: 153.2ms +/- 0.3%
date: 523.6ms +/- 0.6%
format-tofte: 302.4ms +/- 0.6%
format-xparb: 221.2ms +/- 1.3%
math: 931.3ms +/- 0.1%
cordic: 356.0ms +/- 0.2%
partial-sums: 324.5ms +/- 0.1%
spectral-norm: 250.8ms +/- 0.2%
regexp: 1681.6ms +/- 0.1%
dna: 1681.6ms +/- 0.1%
string: 1641.0ms +/- 0.2%
base64: 232.9ms +/- 0.2%
fasta: 261.9ms +/- 0.2%
tagcloud: 394.9ms +/- 0.2%
unpack-code: 525.2ms +/- 0.2%
validate-input: 226.1ms +/- 0.7%

与O32系统的性能相比：9125ms vs 6355ms，慢了一半。一个原因是N32现在没有JIT支持。

正确性方面，使用webkit的 Javascript测试集测试。有7个例子出错：

ecma/Date/15.9.5.14.js
ecma/Date/15.9.5.28-1.js
ecma/Date/15.9.5.29-1.js
ecma/Date/15.9.5.31-1.js
ecma/Date/15.9.5.34-1.js
ecma/Date/15.9.5.35-1.js
ecma/Math/15.8.2.17.js

WebKit-龙项目方面：

• 主要优化JavaScript引擎，
• 现在WebKit虽然能编译，但运行还会报错：

Can't find built framework at "/root/WebKit/WebKitBuild/Release/lib/libQtWebKit.so".

• 这个项目刚刚启动，欢迎加入

您可能也喜欢：

webkit-龙小组成立

龙芯中科公司招聘JAVA虚拟机开发工程师

zzzz龙芯之火，可以燎原（下）

好大一筐梅普斯(MIPS)

GCC即将支持龙芯3A

无觅

相关文章：

• WebKit和Firefox的JavaScript性能对比
• webkit-龙小组成立
• JIT Compiler and Virtual Machine SW Engineer for Web Browsers in Qualcomm
• 使用crossdev安装龙芯的O32 gnu交叉工具链
• 拥有Nanojit龙芯后端的firefox发布(10年1月14日更新)
• 移植软件到64位系统

Native Client (Nacl) 是Google提出的一种让浏览器直接运行机器码的技术，让Web应用可以从客户机上获得更多的性能，同时又不会引起安全问题。这个技术类似于微软的ActiveX。程序员可以使用C++或者其他语言编写web应用程序，再通过Nacl发布。程序中可以调用一些系统服务中安全的API，如声卡或者图形显示等。Nacl能使用的本地系统调用都是已经规定好的，所以安全性有保证。这篇文章介绍如何使用Native Client。

使用Nacal实现图片编辑和分享的应用

图中，灰色部分是不安全的模块。其中IMC，即Inter-Module Communications，模块间通信.  SRPC，即Simple RPC， 简单的远程过程调用机制。 NPAPI，即Netscape Plugin Application Programming Interface，Netscape插件应用编程接口。

因为安全问题，所以Nacl的运行时环境必须禁止很多有安全隐患的系统调用，因此NaCl更加适用于纯计算，或者计算密集的应用，对于需要创建进程，访问文件系统的，通通都要毙掉。不过像cache一样，可信的存储应该可以进行。Nacl会首先做静态分析，在机器码中，找出不安全的系统调用和不安全的指令，这些都能通过反汇编搞定。但还得有运行时环境来保证模块间的通信，让Nacl模块可以和其他Nacl模块和浏览器交互。还有一个问题，硬件例外的处理。比如算数值时溢出了，段错误了，或者被外部中断，因为Nacl的运行时环境将Nacl模块的运行完全屏蔽，所以没辙，遇到终端会直接终止。

PNaCl-兼容可移植性和性能

有了C++之类的语言保证，NaCl的应用的运行效率就有了保证。但还需要开发者预先跟据指令集的不同，编译得到不同的机器码，再根据访问者的CPU分发相应的机器码。问题可想而知：兼容性，可移植性不好。于是Google 想到了热火朝天的LLVM(关于LLVM：《前瞻-全时优化和LLVM-1》《前瞻-全时优化和LLVM-2》《前瞻-LLVM大事记(2004-2010)》).PNaCl就诞生了。

使用LLVM开发Nacl应用流程

使用LLVM，将C/C++代码转换成LLVM中间表示。然后再将中间表示分发给访问者。避免了针对ISA的编译，又能提升性能。LLVM静态编译和动态执行的透明性又使得PNacl的代码更容易调试。LLVM的前端有可以增加诸如Fortran和Objectiv C之类的语言。有个问题，就是PNaCL得以单文件形式分发，不过幸好LLVM工具链提供了在做过程间优化时生成一个bitcode文件的功能。

PNaCl的执行模型

上图是PNacl的执行模型，Bitcode下载到客户机后，通过llc或者ld转换执行，在Nacl的运行时环境中执行。

PNaCl的未来

Google现在基于LLVM的有两个，unladen-swallow和Nacl。JavaScript会被Nacl替代吗？以后Google会用PNacl的后端来替代JavaScript的解释器V8吗？Python如果能用LLVM做后端，C/C++也能扩展到LLVM，那以后会是怎样？

或许有点多虑，就好像每一种语言刚刚出现的时候，都有人认为它会替代所有现有语言。但发展到今天，还没有哪种语言能一统江湖，安全、性能和可移植性本身就是矛盾的，不能兼顾，只有根据应用的取舍。

PNacl的问题

本来的用意是加快执行速度，现在先做一遍翻译，变成bitcode，再做一遍翻译，编程机器码。性能还有保证吗？这个项目2010年二月才开始。还有很长的路要走。

参考：

1. http://code.google.com/p/unladen-swallow/
2. http://en.wikipedia.org/wiki/JavaScript
3. http://nativeclient.googlecode.com/svn/data/docs_tarball/nacl/googleclient/native_client/documentation/getting_started.html
4. http://nativeclient.googlecode.com/svn/data/docs_tarball/nacl/googleclient/native_client/documentation/nacl_paper.pdf
5. http://nativeclient.googlecode.com/svn/data/docs_tarball/nacl/googleclient/native_client/README.html
6. http://nativeclient.googlecode.com/svn/data/site/pnacl.pdf
7. http://googlecode.blogspot.com/2008/12/native-client-technology-for-running.html

您可能也喜欢：

LLVM之爷谈下一代编译器

前瞻- 编译器的bug就不能少点？

有写编译器的冲动？来看看这些网站

关于《编译点滴》的定位和未来

LLVM居然开始做广告了！

无觅

相关文章：

• 前瞻-LLVM大事记(2004-2010)
• LLVM 2.7 发布
• 期待未来-一张趣图
• 通用微处理中的SIMD指令扩展
• 多面体模型是编译器循环优化的未来吗？
• 前瞻-全时优化和LLVM-2

从2004年三月到2010年4月，LLVM共发布了1.2-1.9，2.0-2.7，16个版本，至少每年发布两个版本。详细的历史发布版本和release都能从这里找到。

• 1.2增加了调试信息支持，
• 1.3增加精确垃圾收集功能，
• 1.4增加PowerPC JIT支持，增加通用的编译驱动器和连接器；
• 1.5增加针对Alpha,IA-64和SPARC-V8的代码生成器，新的指令选择机制；
• 1.6指令选择能从机器模型中生成，指令调度支持，支持子目标机代码生成器；
• 1.7向量支持，新的GCC4.0 C/C++前端，Objective C/C++支持，汇编内联支持；
• 1.8DWARF调试支持,循环优化改进；
• 1.9新的X86-64后端，连接时优化能和本机连接器交互；
• 2.0中间表示更新(整型完全无符号化，任意长度位的整型支持),代码生成器更新(软浮点支持),X86,ARM,PowerPC代码生成改进；
• 2.1.gcc-4.2前端，Fortran，Ada和OpenMP支持，MIPS后端支持；
• 2.2 Clang启动，CellSPU后端支持，精确垃圾收集代码重构；
• 2.3, 不再支持gcc4.0前端，vmkit启动(用LLVM实现JVM和CLI)，多返回值支持，llvmc重构，连接时优化起结构重写
• 2.4，增加优化，并缩短O0编译时间，PIC16微处理器支持
• 2.5，启动Pure,LLVM D Compiler,Roadsend PHP;XCore后端支持
• 2.6，启动compiler-rt,KLEE,machine code toolkit,开优化时调试信息行号支持，新MSP430，SystemZ和Blackin后端支持，Gold连接器插件支持
• 2.7，启动LLVM新logo，MicroBlaze后端支持。

以上就是从04年到10年LLVM每次发行新版本中给出的最要新特性.可以看出，几乎和普通的编译器没有什么两样。所做的无非在增加新前端，编译更多的语言，支持新后端，可以在更多的处理器上运行。增加中间优化，调bug。

LLVM近几年的发展路线已经越来越像一个标准的，前端+后端+优化的编译器。运行时的优化也大部分集中在JIT上，反馈制导优化也没有涉及。

Chris Lattener最近几年发表的文章：

1. “Making Context-sensitive Points-to Analysis with Heap Cloning Practical For The Real World”
   PLDI 2007, San Diego, CA, June 2007。
2. “Macroscopic Data Structure Analysis and Optimization”
   Ph.D. Thesis, Computer Science Dept., University of Illinois at Urbana-Champaign, May 2005.
3. “Automatic Pool Allocation: Improving Performance by Controlling Data Structure Layout in the Heap”
   PLDI 2005, Chicago, IL, June 2005.
   PLDI’05 Best paper award.
4. “Transparent Pointer Compression for Linked Data Structures”
   MSP 2005, Chicago, IL, June 2005.

基本也没有太多触及LLVM整体架构的。

另外，Chris Lattener在近几年的几个邀请报告上也简明扼要的讲解了LLVM的架构。

1. “State of Clang” (shared talk) and several other pieces of the meeting, such as the introduction, open discussion forum, etc.
   LLVM Developer Meeting, Cupertino, CA, Oct 2009.
2. “Introduction to the LLVM Compiler System”
   Plenary Talk, ACAT 2008: Advanced Computing and Analysis Techniques in Physics Research, Erice, Sicily, Italy, November 2008.
3. “LLVM and Clang: Next Generation Compiler Technology”
   BSDCan 2008, Ottawa, Canada, May 16-17, 2008.
4. “The LLVM Compiler System”
   2007 O’Reilly Open Source Convention, Portland, OR, July 2007.
5. “LLVM 2.0 and Beyond!”
   Google Tech Talk, Mountain View, CA, July 25, 2007.
6. “LLVM in OpenGL and for Dynamic Languages” (and several others)
   LLVM Developer Meeting, Cupertino, CA, May 2007.
7. “The LLVM Compiler System”
   2007 Bossa Conference on Open Source, Mobile Internet and Multimedia, Recife, Brazil, March 2007.
8. “Introduction to the LLVM Compiler Infrastructure”
   2006 Itanium Conference and Expo, San Jose, California, April 2006.

对比一下Chris最近几年在不同的文献中，对LLVM的架构描述也是很有意思的。

llvm-02 from Chris M.S. Thesis 2002

LLVM CGO2004

LLVM 06 Link-Time Optimization

LLVM 06 Code Generator

LLVM 08

LLVM始终坚持的是LLVM代码在代码生成器，解释执行之间的透明性。重点突破的一直是过程间优化。但架构却基本上摒弃了全时优化，开始走经典的静态分析路线。和GCC、Open64相比，在目的上也没有差别了。
LLVM的性能方面，相比于GCC还逊色不少，和Open64就更没法比了.很遗憾，我没有找到将这三个编译器作性能对比的文章.已有的Open64的数据都是非常老的，没什么可比性。而且编译优化这个东西，差距很大。关键是看有没有人做，投入多大经历做，太老的数据没有什么对比意义。

但LLVM和GCC最新版的对比有， LLVM2.7和GCC 4.5的性能对比(图来自http://vmakarov.fedorapeople.org/spec/）：

• SPEC 2000 整点(-O2)

• SPEC2000浮点(-O2）

• SPEC 2000 整点（-O3）

• SPEC 2000 浮点(-O3)

O2和O3优化下，GCC的性能平均都比LLVM 2.7要好大概2%-3%左右。浮点GCC的优势比整点要大.上面数据仅供参考：）

此外上面的网页中也对编译时间做了对比。LLVM比GCC要快30%左右。

以上数据测试平台：2.93Ghz Intel Core I7 with 8GB memory under Fedora Core10. X86 32位系统.

您可能也喜欢：

LLVM居然开始做广告了！

安装LLVM2.7 step by step

LLVM 2.7 发布

Open64业内外人士对LLVM和Open64的观点

Open64、LLVM、GCC源代码行数对比

无觅

相关文章：

• GCC初窥
• 前瞻-全时优化和LLVM-2
• 探秘CPU性能测试：Spec CPU2000之整点篇
• Open64课程-简介，概述和中间表示
• 前瞻-全时优化和LLVM-1
• Open64课程-结语

LLVM的架构设计：

总览

LLVM的架构设计以让传统的链接时，安装时，运行时和空闲时代码转换都能透明地在LLVM中间表示上展开为目的。上图就是LLVM的高层设计架构。包括静态的编译器前端用于生成LLVM中间表示；连接器用于做连接时优化，尤其是过程间优化。连接器的输出被JIT或者机器代码生成器生成机器代码。在机器代码生成时，可以通过插入低代价的抽样指令来测量运行时的profile，检测热代码，并将空闲时进行优化。

作者认为LLVM的这种架构具有五个优点，这些优点现阶段的编译器或虚拟机等都无法完全具备，它们是：

1. 提供程序的高层信息
2. 离线代码生成器
3. 用户级的profiling和优化
4. 透明的运行时模型
5. 统一的全程序编译

作者比较了如今存在的一些系统，分析它们是否具备以上5点：

• 传统的源码级编译器：能提供2和4，但很难提供1，3，5.虽然也能提供过程间优化，但需要修改Makefile
• 一些商用编译器能够在链接时部分支持1和5，这也是用过将它们的中间表示信息输出到目标文件中。但无法在空闲时使用这些信息
• 高层虚拟机，如JVM和CLI能提供3，部分支持1. CLI部分支持5，因为它支持多语言代码，但很多底层系统代码只能作为不可控代码直接运行。
• 透明的二进制运行时优化系统，如Dynamo和Transmeta能提供2，4，5，但不能提供1，而且对3的支持只在运行时。
• 静态profile制导优化（PGO），能提供3代价是不再对其他阶段透明。另外PGO也有缺点：应用开发者很少用它；使用PGO意味着训练用的输入需要严格和用户行为一致；profiling信息是完全静态的。

当然LLVM也有自己的缺点，作者在文中提到两点：1，源程序语言相关优化需要在前端生成LLVM中间表示之前完成；2，编程语言需不需要一个庞大的运行时系统还有争议。

编译时：外部前端和静态优化

外部静态LLVM编译器(即前端)将源语言程序转换为LLVM虚拟指令集。每种静态编译器都要完成三个关键任务：进行语言相关优化，如使用高层函数优化闭包(closures); 将源程序转换为LLVM代码，并综合尽量多的LLVM类型信息，如指针、结构体和数组信息；启动LLVM的全局或过程间优化。其中第二个任务是外部编译器必须要完成的。LLVM的优化都被写成库的形式，方便前端使用。前端无需构建SSA，可以使用一个栈存放变量，于是就能用栈来实现SSA的构建了。对于所谓的高层语言相关优化，LLVM的观点是：将LLVM优化扩展到特定的转换要好过在编码时为特定语言投入大量的精力。

连接时和过程间优化

LLVM中，连接时是绝大部分分析和转换可以实现的首个编译阶段。LLVM现在包含一些过程间优化，包括：内容相关指针分析；调用图构建；定义-引用分析和过程间转换(内联，死全局变量删除、死参数删除、死类型删除、常数传播、数据越界检查删除、简单结构体域重排、自动存储分配等).LLVM中提供的编译和运行时优化器能加快过程间分析速度。编译时，汇总每个函数的过程间信息，并附在LLVM 代码中。链接时，过程间优化器以这些信息作为输入，而非重新从源码中得到信息。这种技术有效的缩短了编译实践，而且在链接时之前，并未破坏源码的结构。

离线和实时代码生成器

代码生成器用于运行代码前将LLVM中间表示转换为目标平台的机器语言(目前LLVM支持X86和Sparc V9平台).有两种方式实现这种转换，一是在链接时或安装时代码生成器静态地生成高效本地码，这时可以使用代价高的代码生成技术。如果用户打算使用运行时和离线优化器，LLVM中间表示将会附在可执行文件中，并且代码生成器会插入低代价的指令来识别常被执行到的代码区间。另外，LLVM还有一个实时执行引擎，直接在运行时启动代码转换器。

运行时程序行为采集和重优化

LLVM设计的目标之一是开发一种全新的普通应用运行时优化架构。程序执行中，识别最常被执行的路径，通常是热循环。识别出热循环后，复制热区域代码，并使用LLVM代码生成器，优化并生成机器码，并在原始代码和新机器码之间插入一个分支指令。这种机制很强大，理由有三：本地代码生成恩公使用经典算法来产生高性能代码；因为本地代码生成器和运行时优化器都是LLVM的一部分，因此能很好的协同工作，让运行时优化起从代码生成器中得到很好支持；运行时优化起能从LLVM的中间表示中得到高层信息以便实施高度优化。

用户行为信息制导的离线重优化

因为LLVM中间表示能保存，使得应用程序的空闲时离线优化能透明地在用户系统上进行。该优化器可以简单修改连接时过程间优化器来得到，只需要把重点放在目标机相关和反馈信息指导优化即可。

LLVM的评测和应用

评测LLVM

作者评测了LLVM的四个方面：语言无关类型系统的完备性；高级语言特性到LLVM中间表示转换如何实现；LLVM中间表示的复杂度；LLVM的编译速度。

类型系统完备性方面，LLVM使用流敏感，域敏感和内容敏感的指针分析算法来保证LLVM类型系统的可靠性。

高级语言特性方面，作者给出了C++中的隐式调用、模板、基类、虚函数表、例外如何使用LLVM中间表示表达。

LLVM中间表示的复杂度方面，作者对比了GCC3.3 O3下生成X86，Sparc可执行文件和LLVM中间表示文件的大小，结果显示LLVM中间表示大小和X86可执行文件大小相当，明显小于Sparc的可执行文件，作者相信这是LLVM的优势，因为LLVM中间表示使用无限多的寄存器，丰富的类型信息，控制流信息和数据流信息(SSA),而可执行代码没有这些信息。

LLVM的编译速度方面，作者给出了LLVM上几个过程间优化：DGE(aggressive Dead Global variable and function Elimination),DAE(aggressive Dead Argument and return value Elimination),inline转换时间并和GCC O3的编译时间对比，结果显示LLVM做以上三个过程间优化的编译时间要大大短于GCC O3的编译时间，而且GCC O3还没有过程间优化，作者也给出了LLVM的优化效果。

LLVM的应用

LLVM中已经实现的几种技术：如数据结构体分析(Data Structure Analysis)和自动查询分配(Automatic Poll Allocation)都得益于LLVM的架构。

SAFECode:一个安全的低级中间表示和运行环境。该中间表示基于LLVM中间表示，目的是增强程序的存储安全。除了运行时优化外，SAFECode几乎使用了LLVM架构中的所有结构。

虚拟指令集计算机的外部指令系统设计：虚拟指令集处理器可以使用两个完全不同指令集。外在的虚拟指令级和隐藏的内部实现指令集。LLVM的中间表示就能作为一种外部虚拟指令集。

与LLVM相关的工作:

高层语言虚拟机，如SmallTalk，Self，JVM和CLI，需要特定的对象模型和运行时系统支持，但因为太高层，其他语言(如C++)可能很难在该虚拟机上运行。为了可移植性，中间表示需要严格的类型安全，这也限制了对多语言的支持。类型安全的检测也使得很多优化无法进行。

虽然微软的CLI有些支持不同语言的特性。但CLI支持多语言的unmanaged方式使得，部分语言不能用CLI的中间表示完整表达，优化机会也就随之丧失。

Omniware虚拟机和LLVM比较像，因为都实现抽象的低层RISC指令级。但Omniware缺乏高层的类型信息。

Kistler和Franz给出了一个编译器架构，初始代码生成很简单，依靠程序运行行为指导接下来的优化。但不能支持任意语言，而且也没有透明的运行时系统。

类型化的中间表示方面，也有很多相关工作。但多数都为了类型安全，提取高层语言信息。LLVM则重点放在在静态编译优化之外使得经典的程序分析和优化算法能够实现。

统一、通用的中间表示方面也有了不少研究。但几乎都失败了。这些中间表示大多从AST级抽取信息并尽量支持所有源语言特性。LLVM的中间表示更像汇编，使用很小的类型集和低层操作。

过程间优化方面，有的为给定处理器做基于汇编的优化；有些从静态编译器中得到附加信息。但这些都没有考虑运行时和离线优化支持。

也有一些系统提供透明的运行时优化。但这些系统都只是努力的优化机器码。LLVM则是以提供类型，数据流和精确控制流图为目标。

您可能也喜欢：

LLVM居然开始做广告了！

LLVM 2.7 发布

Open64、LLVM、GCC源代码行数对比

安装LLVM2.7 step by step

Open64业内外人士对LLVM和Open64的观点

无觅

相关文章：

• 前瞻-全时优化和LLVM-1
• 前瞻-LLVM大事记(2004-2010)
• Open64课程-简介，概述和中间表示
• GCC初窥
• Open64课程-结语
• Open64课程-编译过程

1，写在前面的话

全时优化(LifeLong Optimization)对于每个编译爱好者来说，太有魅力了。我在起初也是被这个题目所吸引打算一探究竟。本文是04年LLVM的最早两位开发者Chris Lattner和Vikram Adve所写，发表在04年的CGO上，

先来说说LLVM的历史。2000年LLVM开始开发，2005年Apple雇了Chris Lattner，LLVM也相当于成了Apple的官方支持的编译器。Apple已经将它用在OpenCL的流水线优化，Xcode已经能使用llvm-gcc编译代码。可以说05年之前LLVM一直都是学术界的东西，05年之后用于工业界.而这篇文章写在04年.本博最近听过一个关于LLVM的讨论会，会中有资深人士提到LLVM现在越来越像一个普通的编译器。说这番话的意思是，我们可以从这篇文章里找到LLVM的架构设计和早期的一些实现思想，但请不要迷信LLVM现在有多么神奇，每个架构都会有它的优缺点。

这篇文章，我现在已经读完了理论和介绍部分，性能评测部分还没有读。所以标题里面加了个1，因为接下来，还想作几件事，一是读完文章，二是跟踪一下Chris Lattner最近几年的文章，三是尝试将Open64和LLVM做个对比，最后看看代码。所以敬请期待之后的系列文章。

2.总览

先来解释Lifetime:文中分为编译时，链接时，安装时，运行时，空闲时五个阶段。这五个阶段都存在着优化机会：编译时的普通静态优化；链接时的过程间优化；安装时的目标机相关优化；运行时的动态优化和空闲时的profile制导优化。LLVM最早的设计就是针对以上几种优化进行的。

既然需要运行时和空闲时优化，就必须有必要的运行时环境和profile插装方式。因此注定LLVM的中间表示将占据非常重要的位置。编译和链接是为了生成中间表示，运行和空闲时则需要对中间表示的解释和执行。因此LLVM用上了目前编译所开发的所有技术:静态编译优化，JIT，虚拟机，解释器，运行时技术等等。也注定了LLVM要有一整套的工具链和环境来完成上述工作。

作者给出了LLVM架构设计中由于支持全时优化的五个特性，并支持现阶段，并无任何一种系统能同时具备这五个特性，不管是编译器，虚拟机还是其他系统。这五个特性是：

1. 保持程序信息不变
2. 离线本地代码生成
3. 基于用户的profile和优化
4. 透明的运行时模型
5. 统一的全程序编译。

作者从两个角度来论述LLVM对全时优化的支持，一是LLVM的中间表示设计；二是LLVM的整体架构设计。

3.中间表示

LLVM的中间表示采取类RISC指令集，但包含关键的高层类型信息，精确控制流图和数据流图。LLVM的中间表示的几个特性：低层，语言无关的类型系 统；提供保存类型信息又能做类型转换和底层地址运算的指令；两个底层例外处理指令。LLVM中间表示之所以能做到与源程序独立，是因为它使用了比汇编稍大 的底层指令级及存储模型但并不暴露任何实际运行时需求和源程序语义需求。这种中间表示也决定了LLVM的局限性，对于源源转换之类的优化，LLVM就无法 直接在中间表示发力。

作者主要从五个方面介绍了LLVM中间表示的特点：指令集、语言无关的类型信息、存储模型、例外处理截止和三种中间表示形式相互透明(普通文本，二进制和内存中)

指令集：

LLVM的中间表示采用原始处理器中的关键操作，回避物理寄存器、流水线、底层调用转换等细节，但为虚拟寄存器提供了集中类型(布尔型、整型、浮点型、指针),这些虚拟寄存器都采用SSA的形式。LLVM中有31个指令，多数采用了类型重载，且多为三地址形式.LLVM的每个虚拟寄存器都使用SSA的形式，而存储位置则不是SSA，这是因为存储可能存在别名。虚拟寄存器采用SSA能带来精确的定义-使用关系。另外LLVM也简化了控制流图，每个函数都转化为基本块的集合。每个基本块都有LLVM指令序列组成，结束基本块都有一个退出指令，如return，unwind，invoke。

语言无关的类型信息：

LLVM中每个SSA 虚拟寄存器和存储对象都有和其关联的类型，所有的操作也都有严格的类型规则。LLVM的类型系统包括了如下类型:void,bool, signed/unsigned int(8bit to 64bit),single float,double float和四种衍生类型：pointer,array,structure和function。作者认为很多高层的类型都能使用这些类型表示。如C++中的类继承就能使用structure,function和function pointer array 来表示；而且作者也认为以上这些类型基本胜任经典的语言无关的程序分析和优化。因为LLVM的中间表示层次低，就需要支持弱类型语言，因此为提高在LLVM程序中声明类型的可靠性，LLVM使用一些指针分析算法来来判断所访问的内存与指针的类型是否可以可靠的相互转换。LLVM的类型转换仅能通过cast指令从一种类型转换为另一种类型。LLVM的指针算术运算通过getelementptr来实现，该指令力保在做地址运算时指令安全。load和store指令则只负责取和存。

精确存储分配和统一存储模型：

LLVM通过三个指令实现存储操作：malloc，free和alloca。malloc负责在堆上分配带类型的存储位置；free负责释放malloc分配的存储空间；alloca和malloc相似，它分配的是在当前栈帧內分配存储而非堆，该内存将在函数返回时自动收回。LLVM中所有地址对象都被精确分配地址。全局变量和函数定义都被分配一个对象地址。这使得一个 统一的存储模型被建立。

函数调用和例外处理：

对于普通的函数调用，LLVM提供了一个带类型的call指令。LLVM有个与众不同的特性使得低级中间表示能处理高级程序例外，这种特性基于invoke和unwind两个指令实现。这两个指令共同支持了基于栈弹出的抽象例外处理模型。详细的机制论述请参考论文，作者用了将近一页的篇幅来论述。

普通文本、二进制和内存中的表示形式：

LLVM的中间表示是首个能同时等价的在二进制，普通文本和内存中(如编译器内部)表示的。指令集最初的设计就考虑到要能高效的即可作为一个中间表示，又能作为离线代码表示和编译器内部表示，并且在三者之间转换时无需任何语义变化。这三者之间的等价转换使得LLVM调试很方便。

正所谓，中间表示很重要，编译架构也得牛，眼高手低要不得，关键还得看评测。敬请关注下文 LLVM的架构介绍及整体评测。

您可能也喜欢：

LLVM居然开始做广告了！

Open64、LLVM、GCC源代码行数对比

AMD intern and full time compiler position based on OpenCL and LLVM

LLVM 2.7 发布

你好，LLVM 3.0

无觅

相关文章：

• 前瞻-全时优化和LLVM-2
• 前瞻-LLVM大事记(2004-2010)
• GCC初窥
• Open64课程-简介，概述和中间表示
• Open64课程-编译过程
• open64课程–过程间分析优化(IPA)

这篇文章仅仅针对浏览器处理JavaScript的性能作比较，主要在X86平台和龙芯平台。先来解释一下JavaScript，JavaScript是互联网内较为常用的脚本语言，面向对象，主要在浏览器内解释执行，用于生成动态网页，因为很多语言特性受Java影响，所以叫JavaScript。通过JavaScript，浏览器可以运行服务器想要在访问者终端上运行的一些计算程序，以达到更好的浏览体验。

再说说浏览器内核和JavaScript的关系，其实JavaScrip脚本的执行仅仅是浏览器内核的一部分，其他的还有Html语言的解释执行，网页的呈现等等也是内核要做的。之所以这么关心浏览器核心对JavaScript脚本的处理情况，是因为现在的很多应用不再是简单的网页浏览，如gmail，google reader，gooe wave还有一些网页3D特效等等都需要在客户机上作计算，这就需要JavaScript大显身手了。而且越来越多的应用依赖JavaScript，所以现在浏览器对JavaScript的处理速度直接影响着用户体验。目前WebKit的JavaScript引擎SquirrelFish，JavaScript的引擎是SpiderMonkey

目前JavaScript在大多数平台上的处理是靠解释执行的，又因为是动态类型，面向对象。。。，决定了JavaScript执行效率低，所以就诞生了各种针对JavaScript的优化，也有了测试JavaScipt解释器性能的BenchMark，目前常用的是Sunspider和google V8，这篇文章中的对比针对Sunspider测试集。

另外还要说说JIT，Just In time，转换，将部分程序代码直接转换成机器码执行，这种技术在运行时优化中比较常用，JavaScript是解释器，所以JIT在解释器中也是很重要的优化手段。目前X86的webkit和Firefox默认就有JIT支持，但龙芯平台上还没有，本博也是最早对龙芯2F平台有JIT支持的Webkit和firefox  JavaScript引擎作对比的，目前这两个JIT都还没有进入官方的代码库中，感兴趣的朋友可以在下面的前两个链接中找到相关源码。其中webkit的补丁还要做些宏的修改，改动不大。这两个都是从官方源码库checkout出来并修改之后的。其中firefox的JIT部分是由ZSC大牛写出来的，详细的讨论贴和测试结果可以在龙芯论坛看到，见下面的第三个链接。
x86下epiphany(webkit内核)和firefox开了jit之后的性能，如下

webkit Total:                  833.6ms +/- 2.1%
firefox Total:                 1774.4ms +/- 2.7%

（测试环境是我的笔记本 intel Pentium t2390,开了频率调节，所以波动较大)、两个差距：

TEST                   COMPARISON            FROM                 TO             DETAILS

=============================================================================

** TOTAL **:           2.13x as fast     1774.4ms +/- 2.7%   833.6ms +/- 2.1%     significant

=============================================================================

  3d:                  2.96x as fast      257.2ms +/- 2.1%    87.0ms +/- 1.0%     significant
    cube:              3.36x as fast       79.2ms +/- 1.7%    23.6ms +/- 2.9%     significant
    morph:             1.52x as fast       50.4ms +/- 1.4%    33.2ms +/- 3.1%     significant
    raytrace:          4.23x as fast      127.6ms +/- 3.0%    30.2ms +/- 3.4%     significant

  access:              3.26x as fast      237.0ms +/- 4.7%    72.8ms +/- 2.8%     significant
    binary-trees:      8.82x as fast       67.0ms +/- 4.4%     7.6ms +/- 9.0%     significant
    fannkuch:          3.48x as fast       98.2ms +/- 0.6%    28.2ms +/- 3.7%     significant
    nbody:             2.50x as fast       51.4ms +/- 10.3%    20.6ms +/- 3.3%     significant
    nsieve:            -                   20.4ms +/- 56.6%    16.4ms +/- 4.2% 

  bitops:              1.42x as fast       53.8ms +/- 1.9%    38.0ms +/- 0.0%     significant
    3bit-bits-in-byte: *3.10x as slow*      2.0ms +/- 0.0%     6.2ms +/- 9.0%     significant
    bits-in-byte:      -                   11.0ms +/- 8.0%    10.4ms +/- 6.5%
    bitwise-and:       *2.33x as slow*      3.0ms +/- 0.0%     7.0ms +/- 0.0%     significant
    nsieve-bits:       2.62x as fast       37.8ms +/- 1.5%    14.4ms +/- 4.7%     significant

  controlflow:         8.76x as fast       50.8ms +/- 2.0%     5.8ms +/- 9.6%     significant
    recursive:         8.76x as fast       50.8ms +/- 2.0%     5.8ms +/- 9.6%     significant

  crypto:              2.34x as fast       93.8ms +/- 1.7%    40.0ms +/- 2.2%     significant
    aes:               2.57x as fast       54.0ms +/- 3.6%    21.0ms +/- 4.2%     significant
    md5:               2.62x as fast       26.2ms +/- 2.1%    10.0ms +/- 0.0%     significant
    sha1:              1.51x as fast       13.6ms +/- 5.0%     9.0ms +/- 0.0%     significant

  date:                1.87x as fast      275.2ms +/- 2.0%   147.0ms +/- 1.0%     significant
    format-tofte:      2.75x as fast      149.0ms +/- 1.0%    54.2ms +/- 1.0%     significant
    format-xparb:      1.36x as fast      126.2ms +/- 4.0%    92.8ms +/- 1.7%     significant

  math:                1.12x as fast       89.8ms +/- 1.8%    80.2ms +/- 21.7%     significant
    cordic:            2.13x as fast       43.4ms +/- 3.3%    20.4ms +/- 9.2%     significant
    partial-sums:      *1.41x as slow*     34.4ms +/- 2.0%    48.6ms +/- 38.2%     significant
    spectral-norm:     1.07x as fast       12.0ms +/- 0.0%    11.2ms +/- 12.2%     significant

  regexp:              3.73x as fast      125.4ms +/- 15.5%    33.6ms +/- 2.0%     significant
    dna:               3.73x as fast      125.4ms +/- 15.5%    33.6ms +/- 2.0%     significant

  string:              1.80x as fast      591.4ms +/- 3.3%   329.2ms +/- 1.6%     significant
    base64:            *1.24x as slow*     28.4ms +/- 2.4%    35.2ms +/- 1.6%     significant
    fasta:             1.71x as fast      133.0ms +/- 2.3%    78.0ms +/- 4.6%     significant
    tagcloud:          2.81x as fast      169.4ms +/- 3.8%    60.2ms +/- 8.2%     significant
    unpack-code:       1.91x as fast      193.8ms +/- 4.4%   101.6ms +/- 2.7%     significant
    validate-input:    1.23x as fast       66.8ms +/- 5.8%    54.2ms +/- 6.4%     significant

龙芯上的JIT具体对比数据不便透漏，可以从下面第三个链接中找到第一版发布时的测试数据。这里仅仅给出一个对比。webkit之所以with GUI是使用编译出的迷你小浏览器中测试结果，no GUI是使用测试脚本跑出来的结果。

 Webkit with GUI Total:                  6723.4ms +/- 0.5%
        no GUI   Total:                  6355.8ms +/- 0.5%
 Firfox Total 7000 ms 左右。

注： 龙芯中的JIT现在还不够成熟，其中Webkit的JIT仅是针对MIPS III做的，没有针对龙芯的特殊优化。

另外，X86中firefox的版本是3.5.7，龙芯中firefox的版本是3.7pre1.WebKit在X86中版本是epiphany的2.28中的版本，龙芯中为SVN中的2010-01-12 r53114。X86运行环境为Gentoo，Gcc4.4.2,Glibc2.11,龙芯运行环境是玲珑一体机，GCC4.3(龙梦修改版）,Glibc2.10。

对比结果可见：X86中WebKit浏览器的性能要明显优于Firefox，达到两倍之多。龙芯相比起来还有些差距，不过相信优化后龙芯的性能会更好。

参考

https://bugs.webkit.org/show_bug.cgi?id=30144

http://dev.lemote.com/code/firefox-3.7-loongson-jit

http://lemote.com/bbs/viewthread.php?tid=26687&extra=page%3D1

http://en.wikipedia.org/wiki/Google_Chrome

http://ineolee.com/pc/several-browser-core-introduction/

您可能也喜欢：
webkit-龙小组成立	zzMozilla的疯狂构想 Firefox 4将开拓浏览器新疆界	龙芯N32系统上的Squirrelfish性能	JIT Compiler and Virtual Machine SW Engineer for Web Browsers in Qualcomm	擦亮眼睛 “百度Hi”用户协议有猫腻
无觅

相关文章：

• 拥有Nanojit龙芯后端的firefox发布(10年1月14日更新)
• GCC初窥
• 用crossdev装龙芯的n32 gnu交叉工具链
• 使用crossdev安装龙芯的O32 gnu交叉工具链
• Gentoo中的交叉编译利器–crossdev
• 龙芯N32系统上的Squirrelfish性能