1 Before the kernel image is in the memory

1.1 On X86

1. BIOS’s job: start at address 0xFFF0, firstly performs power-on self test(POST) which will check the HW, then hardware-platform specific startup tasks,
   and after the HW is recognized and started correctly,
   BIOS will the partition boot code from the designated boot device’s MBR(Master Boot Record).
2. Boot load’s job-stage 1: find and loads the rest of the boot loader (stage 1.5 and stage 2).
3. Boot load’s job-stage 2: display the GRUB startup menu and chooses the operating system.
   load compressed kernel file( vmlinux kernel image and initrd image) to memory, pass the selected options to kernel, and invoke the kerne image in real mode

boot Process on X86

1.2 On MIPS

MIPS uses PMON as its BIOS and bootload. so PMON will do both HW check, load kernel.

1. firstly start kernel at 0xbfc0000, and this address will map to address 0 in flash. This address is the first instruction in start.S
2. start.S does the initialization of cache. then will call the other init function in PMON
3. then other function in main.c will init the memory, hardwares, and load kernel to memory and pass options.

2 Before start_kernel function

2.1 On X86

1. computer will execute codes in arch/x86/boot/head.S
2. and then it will jump to the C code in arch/x86/boot/main.c.
3. after some work, it will call function go_to_protected_mode()
4. In go_to_protected_mode(), firstly, setup_idt() and setup_gdt() for interrupt table and global description table setup will be called.
   and then protected_mode_jump() is called.
5. Then start_32() is called. It will do some registers initialization, and then call decompress_kernel()
6. After decompress_kernel(), start_32() will do 32-bit mode initialization, and jump to start_kernel function.
   The initialization including :
   • clear the bss segment for the protected mode kernel
   • sets up the final global description table for memory
   • build page tables, enable paging
   • initialize a stack
   • create the final interrupt descriptor table

Before start_kernel

2.2 On MIPS

1. Computer will execute codes in arch/mips/boot/compressed/head.S first
2. It will jump to decompress_kernel in arch/mips/boot/compressed/decompress.c
3. Then kernel_entry function is called. It will init the global time variable jiffies, and some other memory segment initialization.
4. Then the status register, kernel entry point, current_thread_info pointer is init.
   The arg list will also put in register or memory
5. Then start_kernel function is called.

您可能也喜欢：
职场男装搭配颜色合身要领	擦亮眼睛 “百度Hi”用户协议有猫腻	百度Hi策略的猜想	令人振奋的第六感技术	说说静态单赋值（SSA,Static Single-Assignment)
无觅

相关文章：

• Linux 内核中的.S文件
• 通用微处理中的SIMD指令扩展
• Gentoo中的交叉编译利器–crossdev
• Illegal Instruction 错误初窥
• Linux内存的属性
• 好大一筐梅普斯(MIPS)

EKOPath4的新特性

• Significant improvements in performance and robustness(性能健壮性)
• Support for latest Intel® 64 & AMD64 processors（新处理器支持）
• Support for SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, SSE4A & AVX（新SIMD扩展支持)
• New C++ backend and GNU compatible runtime（新C++、GNU兼容的运行时库支持)
• Complete implementation of C++ STL locale library（实现C++ STL本地库)
• Reference counted basic_string using atomic locking
• Thread-safety, including iostream and locale objects(线程安全提升)
• Optimized exception handling（例外控制优化)
• Optimized C and C++ debugging support（C/C++t调试支持优化)
• More Fortran 2003 features（Fortran 2003支持)
• Significantly improved IPA (inter-procedural analysis)（IPA分析提升)
• Runtime improvements（运行时改进)
• New PathAS assembler（新的PathAS汇编器）
• Major overhaul of PathDB for better multi-core support
• Hundreds of bug fixes and much more..

性能对比

高性能编译器最重要的是性能，Phoronix给出了针对某些例子的对比，EKOPath4.0的性能提升。如下，从这几个例子来看，EKOPath4.0的性能比GCC4.5高不少。

另外，Proronix也计划自己编译EKOPath编译器，并综合对比LLVM、EKOPath、GCC和Open64。《编译点滴》也会时刻关注，并第一时间刊登相关内容。

EKOPath4相关链接

• 直接安装二进制版本Pathscale： http://c591116.r16.cf2.rackcdn.com/ekopath/nightly/Linux/ekopath-2011-06-12-installer.run
• 编译器源码： git clone git://github.com/path64/compiler.git
• 调试器(PathDB）源码  git clone git://github.com/path64/debugger.git

Pathscale简介

Pathscale是一家专注高性能编译器解决方案的公司，包括GPU和X86平台的高性能计算，以卖相关服务为主。CTO是Christopher Bergström。Fred Chow是技术方面的领导人。感兴趣的读者可以在#pathscale@freenode IRC上了解更多。 对于中国用户，Pathscale的CTO表示，如果感兴趣的人多，可以单独开#pathscale-cn频道服务,可以先在#pathscale IRC里和他说一声。   虽然EKOPath4自称开源，也的确能从上面的链接中找到编译器，调试器的源代码。但是也有人指出Pathscale一直承诺的开源兑现的力度很不够。下面的这段评论来自这里，

Notes: Before continuing, yes, the open-sourcing of EKOPath 4 is what in recent days on Phoronix has been codenamed Dirndl as the results have been very impressive. Some Phoronix readers were sharp to figure it out within the forums and those following me on Twitter. Originally this open-source announcement was to happen two weeks ago, but since then there have been multiple delays for various reasons. While some Phoronix readers figured out EKOPath 4 was being open-sourced in advance, in some development circles this was already known for a number of days. Three weeks ago, Christopher Bergström (PathScale’s CTO), wrote to the Illumos development list and publicly dropped the EKOPath 4.0.10 binary and said "There will be a more broad and related announcement next week, but PathScale promises to continue providing EKOPath 4 as a free download for Solaris and family." On the Illumos IRC that day, the free EKOPath was again brought up. On a related note, back in April news broke that PathScale was working to develop a "CUDA killer" for the GPU. Back then it was promised it would be open-source and freely licensed.  

Open64和Pathscale的渊源

• 2000年SGI将其 利用GPL协议MIPS Pro64编译器开源
• 2001年University of Delaware 继续维护该编译器，并将其更名为Open64
• 2001-2004年，计算所与Intel合作为安腾处理器基于Open64开发ORC项目，即Open Research Coompiler。
• 2003年，Pathscale开始将该编译器移植到X86平台，并着手优化
• 随后的几年里，Open64和Pathscale的代码相互移植了很多。
• 最近，Pathscale升级到了GPLv3，而Open64还采用GPLv2,使得两者的代码越走越远

您可能也喜欢：

Pathscale招聘Fortran编译器背景工程师

LLVM 2.7 发布

百度Hi正式版发布时间：2008年3月3日?

Open64编译器 5.0版本发布

拥有Nanojit龙芯后端的firefox发布(10年1月14日更新)

无觅

相关文章：

• Open64编译器 5.0版本发布
• Pathscale招聘Fortran编译器背景工程师
• Open64课程-结语
• 最近用hg的一点记录
• 前瞻-LLVM大事记(2004-2010)
• Open64课程-简介，概述和中间表示

昨天，Intel刚刚发布了AVX2指令集，这套指令集在AVX基础上做了扩展，不过要在2013年发布的Haswell处理器上才能支持。参考1给出了AVX2的详细特性。

AVX2指令集概述

相比AVX，AVX2在如下方面做了扩展。

• 支持的整点SIMD数据宽度从128位扩展到256位。Sandy Bridge虽然已经将支持的SIMD数据宽度增加到了256位，但仅仅增加了对256位的浮点SIMD支持，整点SIMD数据的宽度还停留在128位上，
• 增强广播、置换指令支持的数据元素类型、移位操作对各个数据元素可变移位数的支持、跨距访存支持。

跨距访存支持

跨距访存支持即访存时，每个SIMD数据的向量数据元素可以来自不相邻的内存地址。AVX2的跨距访存指令称为”gather”指令，该指令的操作数是一个基地址加一个向量寄存器，向量寄存器中存放着SIMD数据中各个元素相对基地址的偏移量是多少。有了这条指令，CPU可以轻松用一条指令实现若干不连续数据”聚集”到一个SIMD寄存器中。这会对编译器和虚拟机充分利用向量指令带来很大便利，尤其是自动向量化。另外，参考2中对跨距访存指令的功能描述中可以看到，当该指令的偏移地址向量寄存器中任何两个值相同时，都会出GP错。这意味着编译器还是需要些特殊处理才能利用好这条指令。

跨距访存指令

但跨距访存指令仅仅支持32位整点、64位整点、单精度浮点、双精度浮点的跨距访存操作。从参考4可以猜测其实gather指令只是在硬件上分解成若干条32位或64位的微访存指令实现。这就移位着其实一条32×8的SIMD访存其实就是8次32位普通数据访存，其访存延时和延时不确定性会非常大，聊剩于无。

拓宽原有整点SIMD指令

理论上从128位到256位的成倍SIMD宽度扩展能带来一倍的加速。

从128位扩展到256位的整点SIMD指令

位操作指令支持

这些指令在加速数据库压缩、哈希，大数的算术计算方面会有帮助。

新增的位访存操作指令

任意位置的SIMD数据置换支持

这一支持将使编译器可以更灵活的使用这条指令协助自动向量化。像参考5这类工作就能实施在Intel的芯片中。

任意位置数据置换指令支持

向量-向量移位支持

之前Intel上的所有SIMD扩展指令的移位操作仅支持所有SIMD数据同时移位相同的位数，有了向量-向量移位支持，就可以为每个SIMD数据做不同的移位操作。

向量-向量移位操作支持

浮点乘法累积操作

之前的X86处理器上的累积操作多数针对整点数据，这次针对浮点数据增加的60条SIMD操作会给Intel跑浮点Benchmark，比如linpack之类的带来很多加速。

《编译点滴》评论

之前几乎所有在通用微处理器上的SIMD指令，都倾向于一刀切策略，即所有的SIMD操作都针对SIMD数据实施完全相同的操作，并不存在特性化的指令。比如访存都是从一块连续的地址空间直接访存、移位时所有的数据都移动相同的位数，数据置换指令的支持也是最近才出现在通用CPU中的。AVX2的这些支持再次肯定了个性化的趋势，CPU中的SIMD支持朝着GPU的方向大踏步前进，并最终赶上并超越向量机。不得不称赞一下IBM的超前思想。AVX2中的这些特性支持在几年前的Power处理器中就已经出现了。

虽然AVX号称可以扩展到512位甚至1024位的SIMD支持，但是所带来的问题怎么解决，期待AVX3或者AMD的小宇宙爆发，或者威盛的黑马：

1. 理论上，增加1倍的向量数据宽度，将带来2倍的晶体管数量提升。目前，Intel的AVX指令集只实现在片上每个core里，作为core中的一个功能部件，若扩展到1024位，将增加4倍的晶体管。虽然制造工艺也会改进，但功耗还是会很大，怎么解决？
2. 在自动向量化仍然不好用的前提下，普通程序很难利用到这些功能做加速，白白的浪费这些晶体管吗？
3. 这么大的数据计算能力，访存怎么供数？对齐貌似还是没有好的方法。还是要程序员自己吭哧吭哧写向量化代码，调试吗？芯片厂商可以每几年升级一次宽度，但兼容性如何保证，原来有64位、128位、256位分别对应MMX、XMM、YMM寄存器，以后呢？
   

参考

1. http://software.intel.com/en-us/blogs/2011/06/13/haswell-new-instruction-descriptions-now-available/
2. http://software.intel.com/file/36945
3. http://en.wikipedia.org/wiki/Haswell_%28microarchitecture%29
4. http://software.intel.com/en-us/forums/showthread.php?t=83459&o=a&s=lr
5. http://portal.acm.org/citation.cfm?id=1133996

您可能也喜欢：

通用微处理中的SIMD指令扩展

SIMD硬件的发展

Some notes about IBM XL C Compiler

zz 龙芯之火，可以燎原（上）

自动向量化

无觅

相关文章：

• Intel Sandy Bridge怎么给力
• 通用微处理中的SIMD指令扩展
• SIMD硬件的发展
• 前瞻-主流处理器中的数据并行支持(SIMD)
• 期待未来-一张趣图
• 好消息：GodSon-T第一款芯片已经流片归来，正在测试

大肠杆菌和Linux系统的控制网络对比

图片来自《科学松鼠会》，很棒的探索新知的网站：）

生物信息学里把DNA序列看成生物体的操作系统，这张图左侧是大肠杆菌的控制网络，右侧是Linux系统的。

生物体系统本身是非常健壮的，这张图显示，在底层，大肠杆菌有很多层次的供调用资源，因此自恢复能力很强，而我们的计算机系统庞大的上层软件都依赖一个小小的CPU和之上的操作系统内核。

于是，操作系统，编译器中，稍微一个小bug都会导致上层出错，进而整个系统不再可靠。当我们还在抱怨CISC指令系统多么多么复杂，X86指令集和体系结构多么多么混乱，RISC多么多么简洁的时候，有没有想过，简单的系统设计往往意味着健壮性的缺失。我个人非常喜欢简单高效的实现，但我们必须接受一个健壮的系统需要臃肿和冗余的现实。

我们的多核CPU就是实现冗余的契机。又多了一个程序员必须学习并行编程的有利论据！当然也别想着我们的计算机系统能简单的让所有的核都能时刻在我们需要他的时候，对我们的请求快速反应。不需要它时，自觉的自我运行，优化我们计算机中的程序。难！

又或许，所谓的云集算才是真正的冗余保证，云计算系统内部的健壮性又如何保证呢？大量的测试？抑或是继续冗余的CPU和虚拟化技术，最后这些都要回归到那些010101010的bit流，哪里才是回归简洁的地方，就像DNA中的四个碱基一样。 未来太令人期待了！

我们必须要系统健壮起来，只有这样，才能让它更有效率更健壮的运转下去。可靠性设计将会越来越重要。多核，众核，云计算来吧！

PS：现在的多核的核数还远远不够，而且现在的半导体制造技术也很落后。其实8核的CPU在出厂时，至少是有9个以上的核的，因为有成品率问题，到了用户手里时，已经经过检测，只打开了8个核而已。以后咱不超频了，超核！

您可能也喜欢：

并行计算前景-摘要

并行计算前景-引言

并行计算前景-研究动机

关于并行貌似正确的废话-程序语言发展的启示

小议并行计算

无觅

相关文章：

• 探秘CPU性能测试：Spec CPU2000之整点篇
• 《多核编译技术研讨会》记二
• 认识静态链接库
• 前瞻-LLVM大事记(2004-2010)
• 前瞻-主流处理器中的数据并行支持(SIMD)
• GCC初窥

从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课程-编译过程

总体说明：

• 编译GCC需要MPC库
• 故纸堆里的旧系统和很久没有更新和测试的系统在GCC4.5中被标记为待放弃，包括IRIX, Solaris 7, Tru64 UNIX V5.1.
• GCC4.4中标记为待放弃的支持被放弃
• 移除Itanium 1变种支持，但Itanium2编译的程序能在Itanium1上正确执行
• GCC生成的调试信息包括了更多DWARF 3的特性，甚至包含了DWARF4的一些特性.GDB7.0之前的版本将无法使用这些特性.所以调试GCC4.5编译的程序需要使用GDB7.0及以上版本.也可以使用选项 -gdwarf-s  -gstrict-dwarf来禁止生成DWARF4信息，或者-gdwarf-2 -gstrict-dwarf让GCC严格执行DWARF2标准.
• X86上，浮点运算在GCC4.5上使用严格C99语法编译时，可能会运行变慢。这是为了和标准一致，可以通过选项-fexcess-precision=fast来避免严格的标准限制。
• noinline属性不再能阻止整个函数拷贝。但可以通过新的属性noclone做到。

改进：

• -save-temps可以增加参数，该功能让用户可以在并行编译的时候得到编译器的中间文件，但不会在不同的文件夹中使用相同的文件名从而干扰比起。
• 调试信息目标文件也都被放在了同个文件夹下，而不是当前工作目录，这样用户可以在并行编译的时候得到调试信息。
• 集成了MPC库，这样可以让GCC在编译时更精确的评估复杂的算术运算。GCC也可以通过它，对于常数作参数的数学运算类内建函数调用，直接在编译时使用相等的返回值来代替之。包括下列内建函数：cacos, cacosh, casin, casinh, catan, catanh, ccos, ccosh, cexp, clog, cpow, csin, csinh, csqrt, ctan和ctanh。
• 新的链接时优化器(-flto),打开此选项后，GCC会针对每个输入文件，产生bytecode的表示形式，并将其写入每个目标文件的特定ELF区內。链接时，从这些ELF区內读取函数体，并将其实体化为转换单元。这样就可以使得过程间优化能在不同的文件间进行(甚至不同语言间),进而可能提升性能。使用此功能需要在编译时和链接时都增加-flto选项。如果不需要程序输出任何符号，可以联合-fwhopr和-fwhole-program来让过程间优化器执行更加激进的优化。
• 增强自动并行化，现在支持外层循环的并行化。
• 自动并行化能作为Graphite的一部分来打开。在选项-ftree-parallelize-loops=的基础上增加-floop-parallelize-all能打开基于Graphite的优化。(注:Graphite是GCC中使用多面体模型做循环优化的部分)
• 重写基于严格指针的优化架构，会提高生成代码的效率。基于严格指针的优化在打开-fno-strict-aliasing后可用。
• 增加关于函数传参的新优化。试图改变函数原型，避免无用传递，仅传递结构体中特定部分，并将引用传参改为值传参。-O2，-Os及以上级别默认开启此优化。
• 优化异常控制代码。

新语言支持和特定语言改进

• 所有语言：-fshow-colum选项默认打开，错误信息现在有列信息。
• C类语言：若#include的文件未找到，编译器会立即退出；增加一个新内建函数__builtin_unreachable()；增加-Wlogical-op选项，对可能存在的逻辑错误，报警告；嵌入式汇编增加goto特性，允许汇编中的语句直接跳到C中的标号处；C++0x原始strings(raw string)支持；deprecatd树形现在可以增加可选字符串参数,如__attribute__((deprecated(“text string”))),这样，deprecation警告会和字符串一同打印。
• 其他针对各个语言的详细细节请参考官方release。

其他改进：

• 插件支持：可以不通过改变编译器代码来扩展编译器功能。-fplugin=file.so能指定GCC载入动态链接文件file.so，并将其作为编译器的一部分执行。更多的细节请参考相关文档。
• 安装文件夹稍有变动。

参考：

http://gcc.gnu.org/gcc-4.5/changes.html

您可能也喜欢：

GCC几个选项学习

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

GCC如何进出GIMPLE中间表示

仔细端详GCC 4.6的新特性

GCC Internal 中文文档上线

无觅

相关文章：

• GCC初窥
• WebKit和Firefox的JavaScript性能对比
• Open64课程—代码生成(CG)
• Open64课程-简介，概述和中间表示
• GCC中的pie和fpie选项
• open64课程–过程间分析优化(IPA)

下面就开始吧。

首先是keywords和use，因为现在2009还不稳定，而我用的是x86就要增加一堆的keyword，如下：

如果一切顺利的话，接下来就能用了。别忘了看看自己系统支持的中文字体，使用这个命令
$ fc-list :lang=zh-cn
本博用来测试各个字体的test-fonts.tex文件，其他问题日后遇到了再详谈，enjoy it :)

\documentclass[12pt,a4paper]{article}
\usepackage{fontspec}
\setromanfont{AR PL UMing CN}
\begin{document}
{\setromanfont{WenQuanYi Micro Hei Mono}
不需要安装字体，文泉驿等宽微米黑,文泉驛等寬微米黑,WenQuanYi Micro Hei Mono \\}
{\setromanfont{WenQuanYi Zen Hei}
不需要安装字体，文泉驿 正黑 \\}
{\setromanfont{WenQuanYi Zen Hei Mono}
不需要安装字体，文泉驿 正黑 Mono \\}
{\setromanfont{WenQuanYi Zen Hei Sharp}
不需要安装字体，文泉驿 正黑 Sharp \\}
{\setromanfont{AR PL UMing TW}
不需要安装字体, AR PL UMing TW \\}
{\setromanfont{AR PL UMing TW MBE}
不需要安装字体, UMing TW MBE \\}
{\setromanfont{AR PL UMing HK}
不需要安装字体, AR PL UMing HK \\}
{\setromanfont{AR PL UMing CN}
不需要安装字体, UMing CN\\}
{\setromanfont{AR PL UKai CN}
不需要安装字体, UKai CN \\}
{\setromanfont{AR PL UKai HK}
不需要安装字体, UKai HK \\}
{\setromanfont{AR PL UKai TW}
不需要安装字体, UKai TW \\}
{\setromanfont{AR PL UKai TW MBE}
不需要安装字体, UKai TW MBE \\}
{\setromanfont{AR PL KaitiM GB}
不需要安装字体, AR PL KaitiM GB \\}
\end{document}

您可能也喜欢：

Gentoo安装texlive2009–字体

gentoo如何处理被屏蔽(masked)的包 by 杨珂 转自linuxsir

Ebuild and emerge

gentoo的相关配置-make.conf

Gentoo 沙盘简介

无觅

相关文章：

• gentoo如何处理被屏蔽(masked)的包 by 杨珂 转自linuxsir
• Gentoo安装texlive2009–字体
• Gentoo中的交叉编译利器–crossdev
• GCC初窥
• Ebuild and emerge
• 来仔细看看GCC 4.5.0