《关于并行貌似正确的废话》系列文章：
在没有革命性的芯片制造技术之前，咱们必须得接受要想快，只能并行！即使出来了新的CPU制造技术，只要有计算，就需要时间，只要有时间需求，人就想要程序跑的越快越好。这是必须的，除了程序员，没有人会享受程序运行的过程。用计算机的人只想要结果！所以性能，将是永恒的主题。
怎么提升性能?咱们从下往上看。
六 122010
四 302010
因为之前的两篇博文前瞻-全时优化和LLVM-1和前瞻-全时优化和LLVM-2都是基于Chris Lattner 2004年发表在CGO的文章写的。所以需要介绍一下LLVM从2004到2010这六年的变化，LLVM的开发社区很活跃。
从2004年三月到2010年4月，LLVM共发布了1.2-1.9，2.0-2.7，16个版本，至少每年发布两个版本。详细的历史发布版本和release都能从这里找到。
四 292010
上篇文章，以论文为主要依据，介绍了LLVM的概况和中间表示，本篇关注论文的后半部分内容–架构设计和LLVM的整体评测：
LLVM的架构设计：
总览
LLVM的架构设计以让传统的链接时，安装时，运行时和空闲时代码转换都能透明地在LLVM中间表示上展开为目的。上图就是LLVM的高层设计架构。包括静态的编译器前端用于生成LLVM中间表示；连接器用于做连接时优化，尤其是过程间优化。连接器的输出被JIT或者机器代码生成器生成机器代码。在机器代码生成时，可以通过插入低代价的抽样指令来测量运行时的profile，检测热代码，并将空闲时进行优化。
四 282010
LLVM新版本相对于2.6增加了很多新特性并对很多功能做了改进.包括生成代码质量显著提高、生成调试信息的改进以及核心架构生的很多新特性。最令人兴奋的特性是Clang(LLVM的前端)能自举。自举是任何编译器实际开发中最令人兴奋的里程碑，而且也标志着Clang对复杂的C++标准大部分支持。
LLVM是苹果公司主导开发的下一代编译器，目标是能实现全时优化，即在编译时静态分析源代码实现优化；链接时分析所有源码文件做更加激进有效的过程间优化；运行时使用实时编译进行实时优化，并采集使用信息；空闲时利用使用信息实现反馈优化。但目前LLVM还很不完善，很多功能还亟待开发和完善。目前LLVM仅支持C语言和部分C++.
LLVM已经应用在不少场合。如，Google用它作为一个Python解释器的底层实现(Unladen Swallow)。苹果公司用它实现Mac OS中OpenCL的底层支持。
四 162010
距离GCC 4.4的发布一年之久，GNU终于发布GCC 4.5了。新版本带来了很多新特性，包括使用MPC库在编译时完成复杂的算术计算，C++0x支持增强，使用部分Graphite完成自动并行化，支持新的ARM处理器，Intel Atom优化和调优支持，以及AMD Orochi优化支持等。今年稍晚发布的Fedora 14,Ubuntu 10.10,OpenSUSE 11.3，都将有GCC4.5，估计Gentoo马上就会有支持了，磨拳擦掌准备试用喽：）详细支持如下：
总体说明：
- 编译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做到。
四 072010
读论文<LLVM: A Compilation Framework for Lifelong Program Analysis & Transformation> CGO 04
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做个对比，最后看看代码。所以敬请期待之后的系列文章。
Continue reading »
一 172010
读PLDI 04 Best Paper Award 《Automatically Proving the Correctness of Compiler Optimizations》
By Sorin Lerner.Todd Millstein and Craig Chambers in Washington U
本博自从接触编译器到现在,几乎都每天都能听到bug这个关键字,编译器中的bug很痛苦,首先,人写的程序很复杂,编译器设计者很难想出所有的情况并一并处理之;其次,编译器的bug很难调,要先排除程序本身的错,接着需要知道到底是分析时出错还是变换时出错;还有这些错都是在怎样的分析和变换中出了错;最后还要担心错误会不会越不越多,没有对编译器整体的理解,很难给编译器打上正确的补丁,从而有可能这个例子补对了,其他又错了一片.
作者在文章里就编译优化正确性的自动证明做了一些尝试,这些尝试在读完文章之后觉得很了不起,只是这里面提到的工作做下来,也是需要很大的积累和投入.作者的尝试我概括如下:将优化分为转换和具体优化两个部分.代码的转换是所有优化都要做的,而并非所有的转换都是优化,所以作者通过增加利益驱动模块来判断某个转换是否是优化,这样优化的自动证明问题,就变成了某个转换正确性的自动证明问题;正确性的定义:转换前后的语义保持不变.接着作者按照转换依据的信息来自转换语句之前还是之后,将转换分成两种模式,即前向转换模式和后向转换模式.然后分别对这两种模式进行讨论,而自动证明也分别针对这两种模式来论述. Continue reading »
传统的过程內分析，采用很保守的策略，假设所有对过程可见的变量都可能改变,并默认所有可能的操作都有副作用，因此过程內分析和优化非常简单。函数调用对于优化策略来说，隐藏了副作用的信息，虽然inline能够将副作用信息暴露给调用者，但这会大大增加代码量并降低指令局部性，而且并非所有的函数都能inline(如，对于不可预测副作用的函数)。过程间分析(InterProcedural Analysis)就应运而生，被用来作程序调用分析，能够处理inline不能处理的问题。删除不必要的函数调用，做指针和常数传播等。
IPA 提供了完全不同的策略，先分析过程內的信息，如别名和依赖关系，然后将这些信息在调用图(根据过程间的调用关系得到的图)中传播,然后就可以利用这些信息决定将函数特殊化，移除函数中的某些不可能经过的路径或者内联函数。通过这些分析，能降低编译器对存储依赖的不确定性。目前还很活跃的编译器都支持了过程间分析和优化，例如gcc -O3就能默认打开优化，open64可以使用-ipa打开，LLVM也有强大的链接时过程间优化，ICC也有。 Continue reading »
十二 292009
这是gcc maillist中某国际友人 laurent@guerby.net 做的2个小时报告的ppt，报告题目为GCC Toulibre 20091216。最近一直想深入了解gcc，而这个ppt基本包含本博想了解的内容，所以将其翻译并分享到这里。翻译过程中，很多地方可能有错，请大家不吝赐教。原版的ppt见文末。
- 什么是GCC
GCC–GNU Compiler Collection,即GNU 编译器集合。GCC即可作为本地编译器也能作为交叉编译器，它支持很多高级语言和多个编译和目标平台。GCC的网址 http://gcc.gnu.org.它是FSF基金会版权所有的自由软件. Continue reading »
十二 142009
此文是Fred Chow在德拉华大学所讲open64课程讲义的翻译，转载请注明出处 http://www.lingcc.com
Fred Chow 原版讲义见最后一页
Open64课程–过程间分析优化
- IPA的角色
唯一在程序间的优化操作。分析：收集整个程序的信息； 优化：在程序过程之间进行优化。IPA的整个优化效果取决于它之后的优化；IPA也为之后的优化阶段提供了跨文件的信息。
- IPA的流图
近期评论