使用如下命令,统计了一下这三个编译器的代码行数情况。
find . -type f -not -regex '\./\.git.*' | xargs cat | wc -l

结果如下,供参考。这三个编译器使用的都是各个代码库中的最新版本,因为《编译点滴》使用git svn工具,所以命令行里有“git”,而标明的版本号却是SVN的。
Open64(SVN R3782):

open64$ find . -type f -not -regex '\./\.git.*' | xargs cat | wc -l
13164644

LLVM(LLVM R148206, 包含Clang  ):
llvm$ find . -type f -not -regex '\./\.git.*' | xargs cat | wc -l
2468255

GCC(R183190):
gcc$ find . -type f -not -regex '\./\.git.*' | xargs cat | wc -l
12823155

 

Open64的Release manageer刚刚发布了5.0版本。

Continue reading »

 

精确的数据流分析是让编译优化能高效进行的基础。 SSA就是一种高效的数据流分析技术,目前几乎所有的现代编译器,如GCC、Open64、LLVM都有将SSA技术的支持, 不仅仅是编译器,Jikes RVM, HotSpot JVM, .Net的Mono,Python的Pypy, Andoroid的Dalvik,这些虚拟机/解释器中的Just-in-Time Compiler也有了SSA的支持。 Firefox的下一代JavaScript引擎IonMonkey中,也将为其JIT引入SSA。 Continue reading »

 

Pathscale刚刚发布了EKOPath4(http://www.pathscale.com/)

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,使得两者的代码越走越远
 

《编译点滴》的open64 doxygen上线。可以通过这个网址浏览: http://open64.lingcc.com/index.html

依据Open64 官方SVN库的r3448版本创建,采用doxygen 1.7.3版本。删除了已经废弃的gcc 3.3, gcc 4.0前端的代码目录,仅保留gcc4.2.0代码目录。

感兴趣的各位可以通过这个网页,更加直观的了解open64源码。

附赠:

LLVM doxygen: http://llvm.org/doxygen/

 

上篇文章介绍了如何发现编译器中的,现在我们聊聊在已有复现小例子的前提下如何调试编译器。编译器内的错误也分很多种,可能是某些功能实现没有做好,也可能优化出了错,成熟的编译器出错多在优化部分。

拿到测试例子,首先要看这个问题是不是某个编译优化引起的。先保持其他选项不变,使用o0编译。若出错依旧,非编译优化错,否则就是某个优化的问题。接下来就是确定出错阶段或者是出错的优化。其实都是在细化问题。以上基本都是些体力活,需要不停地在gdb中跟踪对比编译器中的各种中间表示和编译器代码中的各种变量值。这也是为什麽一个小例子对编译器调试如此重要。 Continue reading »

 

 

Open64中的自动向量化通过选项-LNO:simd=(0|1|2)控制。该选项告诉编译器使用后端支持的SIMD指令来向量化循环。向量化的支持分成3个级别:

  • 级别0时编译器不进行向量化;
  • 级别1时,编译器仅在没有因使用非最佳对齐策略导致性能下降,而且不会出现浮点运算不精确的情况下做向量化;
  • 级别2时,编译器会做最激进的向量化。默认的选项是-LNO:simd=1

Continue reading »

 

不知不觉,一个多月的时间,Fred Chow的讲义就被翻译完了。感谢那些奉献代码的人,在编译器优化上所做的努力和探索永没有止境。

感谢忍住我蹩脚的英语和汉语,看了这些翻译的朋友们。在这个翻译的过程中,深深感到自己的水平很不足,很多翻译别说雅和达,连信这个简单的要求都很难达到。争取将这些资料进一步的完善,能够给更多的人一个可靠的参考。希望大家多提意见和建议.

单就我个人,还是在翻译的过程中,学到了很多,原先都是单纯的看ppt,但是发现那样的话,印象不顾深刻,所以就决定一点点的翻译。自这个博客创建以来,一直希望能将这里搞成编译爱好者们喜欢的网站,呵呵我将继续努力。
Fred Chow是Open64的几个元老级人物之一,高屋建瓴,统观全局的讲述,让我在翻译的过程中很是佩服,只有在这样的积累下,才能讲出这么详实概括的课程。 Continue reading »

 

此文是Fred Chow在德拉华大学所讲open64课程讲义的翻译,转载请注明出处 http://www.lingcc.com
Fred Chow 原版讲义见最后一页

  • 软件开发指南

使用内部选项来开关每个优化–测试正常后的优化选项默认打开.尽量按照模块化原理开发,相关的模块定义尽量本地化。#ifdef Is_True_On宏来标记来断言和确认的使用。通过断言,确认程序和DevWarns协助debug。虽然包含debug信息的编译器速度慢很多,但是可以尽早的发现错误。

  • Debug辅助工具

四类:抽取某个阶段内和不同阶段间的程序代码(使用选项 -tr???);抽取某个阶段内或不同阶段间的符号表(使用选项 -ts???);分析/优化过程中方便跟踪的工具(使用选项 -tt???);提供能在调试器中调用的打印程序。

  • 存储管理

使用存储池机制(commom/util/memory.c)代替malloc/free.提供任意数量的独立操作的存储池,有类似栈的操作,pop是释放内存的唯一方式。使用基于临时特性的存储池–永久的、PU级的、阶段级的和基本块级的。 Continue reading »

2009-2011© 编译点滴 Suffusion theme by Sayontan Sinha

无觅相关文章插件,快速提升流量