使用如下命令，统计了一下这三个编译器的代码行数情况。
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版本。
精确的数据流分析是让编译优化能高效进行的基础。 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/)
高性能编译器最重要的是性能，Phoronix给出了针对某些例子的对比，EKOPath4.0的性能提升。如下，从这几个例子来看，EKOPath4.0的性能比GCC4.5高不少。
另外，Proronix也计划自己编译EKOPath编译器，并综合对比LLVM、EKOPath、GCC和Open64。《编译点滴》也会时刻关注，并第一时间刊登相关内容。
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.
AMD has opening for Senior Compiler Engineer working on Open64 technology.
Please contact either Dan Tierney or myself for this position.
Senior Compiler Engineer:
AMD is seeking a compiler engineer who will work with AMD processor architects
and the AMD Open64 development team to advance the state of Open64 compiler
support for AMD microprocessors.
Location:
Portland, OR (preferred) or Sunnyvale, CA
Job Functions:
Implementation of state of the art compiler optimizations in the Open64 compiler
to improve code quality and performance. Integration of these optimizations into
the Open64 public repository. Performance analysis of benchmarks and real-world
applications to identify compiler code quality issues.
Preferred Education and Experience:
BS and 7+ years experience, MS and 5+ years experience, or PhD and 1+ years
experience in compiler development. Thorough knowledge of x86, AMD64,
SSE/SSE2/SSE3/SSE4/AVX ISA. Understanding of microarchitectural differences
between modern x86/AMD64 processors. Working knowledge of compiler
optimizations and algorithms. 3+ years of Linux in an open source or commercial
development environment. Very solid practical C/C++ experience. Strong
debugging/analysis skills. Good interpersonal and communication (written and
oral) skills.
Contact:
Dan Tierney, dan.tierney@amd.com, 408-749-5585
Website:
https://www.amd.apply2jobs.com/index.cfm
信息来源：
Open64 MailList
《编译点滴》的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的强项在后端优化，为了避免重新开发，使用了gcc的前端。编译器能发现的大部分错误在词法和语法分析中。所以使用gcc的前端，能让open64具备和gcc一样强大的查错功能。
Open64历史上使用过三个版本的gcc前端，gcc3.3， gcc4.0和gcc4.2. gcc3.3是open64目录下对应的kgccfe(gcc前端)和kg++fe(g++前端).现在几乎都使用最新的gcc4.2,前两个版本几乎已经废弃。所以将以gcc4.2前端为例介绍之。 Continue reading »
Open64中的自动向量化通过选项-LNO:simd=(0|1|2)控制。该选项告诉编译器使用后端支持的SIMD指令来向量化循环。向量化的支持分成3个级别:
| 2009-2011© 编译点滴 | Suffusion theme by Sayontan Sinha |
近期评论