编译点滴 » gcc http://www.lingcc.com 编译器、虚拟机、程序设计语言、体系结构、软件调试、操作系统等等 Sat, 04 Feb 2012 06:56:05 +0000 en hourly 1 http://wordpress.org/?v=3.3.1 Open64、LLVM、GCC源代码行数对比 http://www.lingcc.com/2012/01/15/11963/ http://www.lingcc.com/2012/01/15/11963/#comments Sun, 15 Jan 2012 11:59:30 +0000 erlv http://www.lingcc.com/?p=11963 [...]
您可能也喜欢：
Open64业内外人士对LLVM和Open64的观点
open64中的gcc前端
Open64编译器 5.0版本发布
Open64课程–OpenMp和自动并行化
Open64课程–付诸实践(Practical Matters)
无觅

相关文章：

]]> 使用如下命令，统计了一下这三个编译器的代码行数情况。
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业内外人士对LLVM和Open64的观点
open64中的gcc前端
Open64编译器 5.0版本发布
Open64课程–OpenMp和自动并行化
Open64课程–付诸实践(Practical Matters)
无觅

相关文章：

]]> http://www.lingcc.com/2012/01/15/11963/feed/ 2 Linux 内核中的.S文件 http://www.lingcc.com/2011/12/05/11872/ http://www.lingcc.com/2011/12/05/11872/#comments Mon, 05 Dec 2011 05:37:21 +0000 erlv http://www.lingcc.com/?p=11872 [...]
您可能也喜欢：
Linux内存的属性
GNU工具链学习笔记
Linux内存管理中的分页
Strace命令介绍
zz Linux下的段错误的原因及调试
无觅

相关文章：

]]> 接触过内核的朋友肯定在源码中看到许多.S文件，这些文件中基本都是汇编。
这些文件是干什么的，为什么要这么写？

1 .S 文件们

$ find . -name "*.S" | wc -l
1235

可以看到在Linux kernel 3.1的内核中，有上千个.S文件。
这些文件多数分布在arch/下各个体系结构中。
如下是X86的.S文件：

./arch/x86/power/hibernate_asm_64.S
./arch/x86/power/hibernate_asm_32.S
./arch/x86/boot/compressed/head_32.S
./arch/x86/boot/compressed/vmlinux.lds.S
./arch/x86/boot/compressed/head_64.S
./arch/x86/boot/bioscall.S
./arch/x86/boot/header.S
./arch/x86/boot/pmjump.S
./arch/x86/boot/copy.S
./arch/x86/net/bpf_jit.S
./arch/x86/vdso/vdso-layout.lds.S
./arch/x86/vdso/vdso.S
./arch/x86/vdso/vdso32.S
./arch/x86/vdso/vdso.lds.S
./arch/x86/vdso/vdso-note.S
./arch/x86/vdso/vdso32/syscall.S
./arch/x86/vdso/vdso32/note.S
./arch/x86/vdso/vdso32/sysenter.S
./arch/x86/vdso/vdso32/sigreturn.S
./arch/x86/vdso/vdso32/vdso32.lds.S
./arch/x86/vdso/vdso32/int80.S
./arch/x86/math-emu/div_small.S
./arch/x86/math-emu/reg_u_mul.S
./arch/x86/math-emu/reg_u_sub.S
./arch/x86/math-emu/wm_sqrt.S
./arch/x86/math-emu/div_Xsig.S
./arch/x86/math-emu/shr_Xsig.S
./arch/x86/math-emu/polynom_Xsig.S
./arch/x86/math-emu/round_Xsig.S
./arch/x86/math-emu/reg_round.S
./arch/x86/math-emu/reg_u_add.S
./arch/x86/math-emu/mul_Xsig.S
./arch/x86/math-emu/reg_u_div.S
./arch/x86/math-emu/reg_norm.S
./arch/x86/math-emu/wm_shrx.S
./arch/x86/xen/xen-asm_32.S
./arch/x86/xen/xen-head.S
./arch/x86/xen/xen-asm.S
./arch/x86/xen/xen-asm_64.S
./arch/x86/lguest/i386_head.S
./arch/x86/crypto/aesni-intel_asm.S
./arch/x86/crypto/aes-i586-asm_32.S
./arch/x86/crypto/ghash-clmulni-intel_asm.S
./arch/x86/crypto/salsa20-x86_64-asm_64.S
./arch/x86/crypto/aes-x86_64-asm_64.S
./arch/x86/crypto/salsa20-i586-asm_32.S
./arch/x86/crypto/twofish-x86_64-asm_64.S
./arch/x86/crypto/twofish-i586-asm_32.S
./arch/x86/kernel/relocate_kernel_32.S
./arch/x86/kernel/head_32.S
./arch/x86/kernel/relocate_kernel_64.S
./arch/x86/kernel/reboot_32.S
./arch/x86/kernel/syscall_table_32.S
./arch/x86/kernel/vmlinux.lds.S
./arch/x86/kernel/trampoline_32.S
./arch/x86/kernel/trampoline_64.S
./arch/x86/kernel/entry_64.S
./arch/x86/kernel/vsyscall_emu_64.S
./arch/x86/kernel/head_64.S
./arch/x86/kernel/verify_cpu.S
./arch/x86/kernel/entry_32.S
./arch/x86/kernel/acpi/realmode/wakeup.lds.S
./arch/x86/kernel/acpi/realmode/bioscall.S
./arch/x86/kernel/acpi/realmode/wakeup.S
./arch/x86/kernel/acpi/realmode/copy.S
./arch/x86/kernel/acpi/wakeup_32.S
./arch/x86/kernel/acpi/wakeup_rm.S
./arch/x86/kernel/acpi/wakeup_64.S
./arch/x86/platform/olpc/xo1-wakeup.S
./arch/x86/platform/efi/efi_stub_32.S
./arch/x86/platform/efi/efi_stub_64.S
./arch/x86/lib/memcpy_64.S
./arch/x86/lib/cmpxchg8b_emu.S
./arch/x86/lib/rwlock.S
./arch/x86/lib/iomap_copy_64.S
./arch/x86/lib/atomic64_386_32.S
./arch/x86/lib/copy_page_64.S
./arch/x86/lib/memmove_64.S
./arch/x86/lib/thunk_32.S
./arch/x86/lib/copy_user_nocache_64.S
./arch/x86/lib/rwsem.S
./arch/x86/lib/cmpxchg16b_emu.S
./arch/x86/lib/clear_page_64.S
./arch/x86/lib/memset_64.S
./arch/x86/lib/msr-reg.S
./arch/x86/lib/atomic64_cx8_32.S
./arch/x86/lib/getuser.S
./arch/x86/lib/csum-copy_64.S
./arch/x86/lib/thunk_64.S
./arch/x86/lib/putuser.S
./arch/x86/lib/copy_user_64.S
./arch/x86/lib/checksum_32.S
./arch/x86/ia32/ia32entry.S

可以发现休眠、启动、数学运算、虚拟机支持、加密、锁机制、系统调用有关。
这些功能之所以使用汇编而非普通C语言，有两方面的原因

  • 实现特权控制
  • 加速

1.1 实现特权控制

Linux内核要管理的是整个计算机系统，拥有最高的权限。
通过访问和修改特权特权寄存器、执行特权指令的方式控制和调度各种计算机资源。
这些功能虽然可以直接通过GCC生成汇编的方式做到。
但是，相比在编译器里通过复杂的程序分析折腾，反倒是简单的通过汇编实现更加灵活高效。
而且这种功能并不会被经常使用，做进去意义不大。

以arch/x86/kernel/entry32.S为例。
这个文件定义了X86平台下的中断向量数组。
使用汇编来实现，能让程序员更灵活的控制所生成的汇编文件。
这个文件中，使用两个.rept元语就能轻松创建一个很大的数据段。

1.2 实现加速

对于指针经常出没的系统软件，编译器很难完全保证别名分析准确无误，只能作最保守的程序变换。
在系统软件这种基础架构中，性能也是非常重要的。所以为了尽可能的加速，汇编也被广泛的利用起来。

为什么要把整个文件都写成汇编，而不是直接在函数中写嵌入式汇编呢？
以arch/x86/crypto/aesni-intelasm.S为例,这个文件先下面形式定义了一对汇编形式的宏
.macro XXXX PARM1 PARM2
… …
.endm

之后定义了函数aesnigcmdec，也是使用汇编的形式。
其实整个文件就相当于一个拥有部分高级语言特性的汇编文件。
经过编译器的处理后，变成普通汇编文件。
需要调用这些函数的时候，就在普通C语言文件中直接调用即可。
所以用这种汇编能达到普通C语言的效果。

之所以不使用嵌入式汇编，个人觉得是因为嵌入式汇编是把汇编嵌到C语言生成的汇编中。
在编译器看来，需要对嵌入式汇编所破坏的程序运行环境，如寄存器,作保存和恢复操作，代价很高。

1.3 .S如何如何整合到内核二进制文件中

该文件会先经编译器处理，在MIPS平台上，对于.S文件编译命令行如下：

mips64el-unknown-linux-gnu-gcc -Wp,-MD,arch/mips/kernel/.entry.o.d -nostdinc -isystem
 /home/cross-loongson/bin/../lib/gcc/mips64el-unknown-linux-gnu/4.4.1/include
-I/home2/linux-2.6.35.2-gcc/arch/mips/include -Iinclude -include include/generated/autoconf.h
-D__KERNEL__ -DVMLINUX_LOAD_ADDRESS=0xffffffff80100000 -DDATAOFFSET=0
-ffunction-sections -mabi=64 -G 0 -fno-pic -pipe -msoft-float -ffreestanding -mips64 -U_MIPS_ISA -D_MIPS_ISA=_MIPS_ISA_MIPS64
-Wa,-mips64 -Wa,--trap -I/home2/linux-2.6.35.2-gcc/arch/mips/include/asm/mach-malta
-I/home2/linux-2.6.35.2-gcc/arch/mips/include/asm/mach-generic
-c -o arch/mips/kernel/entry.o arch/mips/kernel/entry.S

-D__ASSEMBLY__  -gdwarf-2

对比普通C语言文件的编译命令行如下：

mips64el-unknown-linux-gnu-gcc -Wp,-MD,arch/mips/mm/.uasm.o.d -nostdinc -isystem
/home/cross-loongson/bin/../lib/gcc/mips64el-unknown-linux-gnu/4.4.1/include
-I/home2/linux-2.6.35.2-gcc/arch/mips/include -Iinclude -include include/generated/autoconf.h
-D__KERNEL__ -DVMLINUX_LOAD_ADDRESS=0xffffffff80100000 -DDATAOFFSET=0
-ffunction-sections -mabi=64 -G 0 -fno-pic -pipe -msoft-float -ffreestanding -mips64 -U_MIPS_ISA -D_MIPS_ISA=_MIPS_ISA_MIPS64
-Wa,-mips64 -Wa,--trap -I/home2/linux-2.6.35.2-gcc/arch/mips/include/asm/mach-malta
-I/home2/linux-2.6.35.2-gcc/arch/mips/include/asm/mach-generic
 -c -o arch/mips/mm/uasm.o arch/mips/mm/uasm.c

 -Wframe-larger-than=2048 -fno-stack-protector -fomit-frame-pointer -g -Wdeclaration-after-statement -Wno-pointer-sign -fno-strict-overflow
 -fconserve-stack -Werror -DKBUILD_STR(s)=#s -DKBUILD_BASENAME=KBUILD_STR(uasm) -DKBUILD_MODNAME=KBUILD_STR(uasm)
 -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -Werror-implicit-function-declaration -Wno-format-security
 -fno-delete-null-pointer-checks -Os

最下面空格隔开的部分是二者的不同之处。可见普通.c文件多了很多编译控制选项。

最终，.S输出的.o文件和其他文件一起链接到内核二进制文件中:

mips64el-unknown-linux-gnu-ld -m elf64ltsmip -r -o arch/mips/kernel/built-in.o
...
arch/mips/kernel/entry.o

2 参考

您可能也喜欢：
Linux内存的属性
GNU工具链学习笔记
Linux内存管理中的分页
Strace命令介绍
zz Linux下的段错误的原因及调试
无觅

相关文章：

]]> http://www.lingcc.com/2011/12/05/11872/feed/ 0 GCC如何进出GIMPLE中间表示 http://www.lingcc.com/2011/11/29/11859/ http://www.lingcc.com/2011/11/29/11859/#comments Tue, 29 Nov 2011 06:00:18 +0000 erlv http://www.lingcc.com/?p=11859 [...]
您可能也喜欢：
open64中的gcc前端
GCC几个选项学习
GCC Internal 中文文档上线
Open64、LLVM、GCC源代码行数对比
仔细端详GCC 4.6的新特性
无觅

相关文章：

]]> GIMPLE中间表示，是GCC中机器无关的中间表示，机器无关的优化基本都在这个层次上做。
本文先来看看GCC是如何进、出GIMPLE中间表示的。

1 从 GENERIC 到GIMPLE

GENERIC是GCC最顶层的语言无关中间表示。
GCC 利用 “gimplifier” 将 GENERIC 中间表示转换为 GIMPLE中间表示。
因为GENERIC 是语法树形式的，所以这个转换过程是递归的。

对于一个函数，GENERIC中间表示将其存储在FUNCTION_DECL树节点中的DECL_SAVED_TREE域中。
然后通过调用函数gimplify_function_tree将其转换为GIMPLE.
具体的转换过程一般是 gimplify.c: gimplify_function_tree -> gimplify_body -> gimplify_stmt -> gimplify_expr .

GIMPLE中有一个lower的动作，用于将高层次的GIMPLE表示，解析成低层次的，这个lower动作在pass_lower_cf中完成。
比如，嵌套的作用域和表达式。 可以使用选项 -fdump-tree-gimple得到类C的GIMPLE表达形式

如下面程序：

int main()
{
  int a;
  if (a)
    {
      int b;
      b = 2 + a + b;
    }
  return 0;
}

使用该选项得到的转换成C语言形式的GIMPLE中间表示为：

main ()
{
  int D.1593;
  int D.1594;
  int a;

  if (a != 0) goto <D.1591>; else goto <D.1592>;
  <D.1591>:
  {
    int b;

    D.1593 = a + 2;
    b = D.1593 + b;
  }
  <D.1592>:
  D.1594 = 0;
  return D.1594;
}

2 从 GIMPLE 到 RTL

做完机器无关优化之后，GCC会将GIMPLE转换为RTL中间表示。
在RTL上，基本都是机器相关的优化，以及寄存器分配，指令调度等功能。
从GIMPLE到RTL中间表示，则是在expr.c:expand_expr_real中，

您可能也喜欢：
open64中的gcc前端
GCC几个选项学习
GCC Internal 中文文档上线
Open64、LLVM、GCC源代码行数对比
仔细端详GCC 4.6的新特性
无觅

相关文章：

]]> http://www.lingcc.com/2011/11/29/11859/feed/ 4 Open64编译器 5.0版本发布 http://www.lingcc.com/2011/11/10/11799/ http://www.lingcc.com/2011/11/10/11799/#comments Thu, 10 Nov 2011 13:50:10 +0000 erlv http://www.lingcc.com/?p=11799 您可能也喜欢： Open64、LLVM、GCC源代码行数对比 AMD编译器开发工程师介绍Open64编译器 Open64课程-循环嵌套优化(LNO) Open64课程–OpenMp和自动并行化 Open64业内外人士对LLVM和Open64的观点 无觅

相关文章：

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

主要改动包括：

  • 增加configure脚本支持
  • 增加VCG图形支持，以便生成控制流图
  • 增加对volatile变量的支持
  • 增加对域敏感别名分析的支持
  • 更多的代码性能提升
    • if分支转换改进
    • 控制流图优化改进
    • 循环优化改进
    • 内联优化改进
    • 提升-O3的浮点性能
    • 增加结构体优化
    • 提升向量化优化
    • C++代码优化
  • 代码生成部分改进
    • 支持SSE4.2,AVX，FMA指令
    • 减小指令调度时的寄存器压力
    • 基本快的padding和代码对齐改进
    • 针对Bulldozer处理器的优化和调优
  • 其他注记
    • 将在下个版本中取消gcc 3.x前端支持
    • IRIX系统支持也将在下个版本取消

目前，能在生产环境中使用的编译器主要有GCC(GPL v3), LLVM(BSD) 和Open64（GPLv2）。phoronix最近对这三款编译器做了一些性能对比，虽然所选benchmark不如SPEC CPU那么权威，但还是有些参考价值。

Reference：

您可能也喜欢：
Open64、LLVM、GCC源代码行数对比
AMD编译器开发工程师介绍Open64编译器
Open64课程-循环嵌套优化(LNO)
Open64课程–OpenMp和自动并行化
Open64业内外人士对LLVM和Open64的观点
无觅

相关文章：

]]> http://www.lingcc.com/2011/11/10/11799/feed/ 0 说说静态单赋值（SSA,Static Single-Assignment) http://www.lingcc.com/2011/08/13/11685/ http://www.lingcc.com/2011/08/13/11685/#comments Sat, 13 Aug 2011 10:52:24 +0000 erlv http://www.lingcc.com/?p=11685 [...]
您可能也喜欢：
Open64 课程–全局标量优化(WOPT I) part II
Open64 课程–全局标量优化(WOPT II)
Open64 课程–全局标量优化(WOPT I) part 1
open64课程–过程间分析优化(IPA)
Open64编译器 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。

可以看到，几乎所有热门的语言所用的热门编译器/解释器/虚拟机中都有了SSA。

1 SSA是什么？

SSA即静态单赋值，Static Single-Assignment，这是一种中间表示形式。 之所以称之为单赋值，是因为每个名字在SSA中仅被赋值一次.

如下图中的一段程序的控制流图。从这张图中可以看到，最后一个基本块中y值的定义或者来自左侧的分支，或者来自右侧的分支。

SSA_example1.1

SSA_example1.1

将每个赋值语句中的变量赋予一个唯一的名称后，一般新名称采用原变量+版本号（Version）的形式。 对于上面这段控制流图，就变成如下形式：

SSA_example1.2

SSA_example1.2

这张图中有个问题，有分支时，若分支中有对变量的操作，就无法确定使用了哪个版本的变量。 因此，引入了PHI节点。如下图所示：

SSA_example1.3

SSA_example1.3

PHI将分支中的y1和y2连接，并生成一个新的定义y3。有了PHI节点后，最后一个基本块中y3的定义来自之前的PHI节点，PHI节点中的两个操作数y1和y2分别来自左右两个分支。

2 SSA的作用

在SSA中间表示中，可以保证每个被使用的变量都有唯一的定义，即SSA能带来精确的使用–定义关系。 而在图SSA_example1.1中的y值定义却非常模糊。

概括起来，SSA带来四大益处：

  • 因为SSA使得每个变量都有唯一的定义，因此数据流分析和优化算法可以更加简单
  • 使用-定义关系链所消耗空间从指数增长降低为线性增长。若一个变量有N个使用和M个定义，若不采用SSA，则存在M×N个使用-定义关系。
  • SSA中因为使用和定义的关系更加的精确，能简化构建干扰图的算法
  • 源程序中对同一个变量的不相关的若干次使用，在SSA形式中会转变成对不同变量的使用，因此能消除很多不必要的依赖关系。

有了精确的对象使用–定义关系，许多利用使用–定义关系的优化就能更精确、更彻底、更高效。如

  • 常数传播
  • 死代码删除
  • 全局
  • 部分冗余删除
  • 强度削弱
  • 寄存器分配

2.1 SSA与寄存器分配

因为SSA使得依赖分析更加简单、精确，而且PHI节点中的变量不可能同时活跃。因此在SSA形式能协助完成寄存器分配。 实际上，GCC最早的SSA就是GCC 3中RTL阶段。

3 SSA的转换

讲了这么多有关SSA的优点，接下来介绍一下一般编译器构建SSA的方式。

3.1 从普通中间表示到SSA

两步走战略：

  • 插入PHI节点： PHI节点要插在控制流图的汇聚点处（joint point), 只要在汇聚点之前的分支中有针对某个变量的修改， 就需要在该汇聚点插入针对该变量的PHI节点。 PHI节点的操作数是分支路径中重新定义的变量。
  • 变量重命名： 在插入PHI节点后，SSA中所有针对变量的定义就具备了，接下来就依次在定义处重命名变量，并替换对应的变量使用处。

此外，为了节省内存空间，简化SSA上的算法，我们需要将插入的PHI节点数目最小化。 因为PHI节点本身只是一个概念性的节点，若插入过多不必要的PHI节点，算法就需要在控制流图的汇聚点针对每个分支做分析。 可以借用变量的支配边界（dominance frontier)进行PHI节点数目最消化。一般都通过直接计算支配边界的方式插入PHI节点。

3.2 从SSA到普通中间表示

为什么还要从SSA转换回去呢？很简单，处理器不能直接执行PHI节点对应的操作。最简单的做法，直接拷贝，如下图所示：

out of ssa

out of ssa

但这样有一个问题，如下图。简单的拷贝算法可能改变代码的语义：

out of ssa problem

out of ssa problem

正确的做法：

  • 对PHI节点的操作数和结果重命名，使其名称相同，即变成同一个变量
  • 再在分支中插入拷贝操作

4 更复杂情况下的SSA

4.1 数组、指针等别名

上面关于SSA的讨论基本都是针对单个简单变量的SSA操作，那么对于复杂的指针、数组之类的访存,SSA应该如何处理呢？ 数组和指针使得编译器无法确定define和use的具体变量。

参考资料7给出了一种定义方式，通过引入maydef，mayuse和zero version使得编译器也能对别名（即指针和数组）存在的程序做SSA分析。 若通过指针为其所指区域赋值，就在此处插入maydef，表示可能对变量做了定义。同理，对使用指针所指向区域的值的，就插入一个mayuse。 因为无法确定指针所指向的到底是哪个变量，为了正确性，需要对所有变量都插入maydef动作。同样mayuse也是针对所有变量的。

当指针操作较多时，这种方式就会引入过多的新变量版本。因此就增加了zero version。 zero version的作用就是尽量把maydef所带来的版本数降低。 将那些很可能不会别名的都使用相同的zero version。 比如某个变量通过maydef产生了一个新版本之后，若还会有新的maydef操作，则直接生成zero version，不再生成新的version。

4.2 堆上的存储

在堆上分配的存储空间，一般编译器都将整个堆看作一个对象，来做SSA。

4.3 复合结构–结构体

因为结构体也是由很多元素构成的，所以就存在两种处理方式：把结构体整个看作一个整体做SSA、把结构体的每个元素看作一个对象做SSA。 后者相比前者，因为分的更细，在结构体操作频繁的程序中能带来不错的优化效果。

5 GCC中的SSA

GCC的SSA

  • tree-ssa.c
  • tree-into-ssa.c:将函数转换为SSA形式，插入PHI节点，对于未初始化的变量给出警告。
  • tree-ssa-dce.c:扫描整个函数，标记无副作用且结果并未被使用的语句，所有存储操作都视为有副作用。
  • tree-ssa-dom.c:支配关系相关优化：复写传播、常数传播、表达式简化、冗余消除、Jump Threading？
  • tree-ssa-forwprop.c:前向传播单一引用变量，通过将仅使用一次的变量用相应的表达式替代来尝试容易删除。
  • tree-ssa-copyrename.c:尝试将由拷贝动作产生的SSA变量用原变量替换之，优化符号表。
  • tree-ssa-phiopt.c: 识别表达条件表达式的phi节点，并将其重写为直线代码。
  • tree-ssa-alias.c:流敏感基于SSA的指向分析，得到可能-别名，一定-别名和逃逸分析信息。 这些信息将用于将变量从内存中地址可用对象提升为非别名变量，这样这些变量就能使用SSA形式的分析和优化了。
  • tree-ssa-structalias.c:用于过程间的指向分析。
  • tree-sra.c:将合适的无别名局部复合变量转换为一个标量集合，并进而转换为SSA形式。
  • tree-ssa-dse.c:删除那些无用的存储操作
  • tree-ssa-sink.c:将存储和赋值语句尽量下沉到和它们的使用点接近的位置。
  • tree-ssa-pre.c:部分冗余删除、load语句移动、完全冗余删除
  • tree-ssa-loop.c: SSA形式的循环优化
    • tree-ssa-loop-im.c:循环无关语句移动
    • tree-ssa-loop-ivcanon.c:循环标准化
    • tree-ssa-loop-ivopts.c:索引变量优化
    • tree-ssa-loop-unswitch.c:将循环无关的条件跳转移到循环外
    • tree-vectorizer.c, tree-vect-analyze.c, tree-vect-transform.c:自动向量化
  • tree-ssa-ccp.c:条件常数传播
  • tree-ssa-copy.c:条件复写传播
  • tree-vrp.c:取值范围传播
  • tree-outof-ssa.c:从SSA形式转换回普通形式

6 open64 中的SSA

open64中的SSA主要用于循环嵌套优化、过程间优化以及普通的函数内优化。 除了循环变换和内联优化外的所有机器无关优化都基于SSA做。 这部分可以说是Open64的重要卖点，对应的代码在osprey/be/opt下。

Open64在没有过程间优化时，主要以函数为单位进行，基于控制流图和别名分析得到的信息构建SSA。

  • opt_goto.cxx：goto语句转换，方便做SSA
  • opt_loop.cxx：循环正规化
  • opt_sym.cxx：构建相关符号表
  • opt_alias_class.cxx：别名分类，方便别名分析
  • opt_cfg.cxx：构建控制流图，包括支配树，不可到达代码识别，if语句转换
  • opt_tail.cxx：尾递归消除
  • opt_alias_analysis.cxx：流无关别名分析
  • opt_ssa.cxx：构建基于WHIRL的SSA
  • opt_dse.cxx：死store删除
  • opt_htable.cxx：构建HSSA–基于哈希的全局值编号SSA
  • opt_ivr.cxx：索引变量标准化
  • opt_prop.cxx：复写传播
  • opt_revise_ssa.cxx：将非直接变量展开成直接变量
  • opt_dce.cxx：死代码删除
  • opt_cfg_trans.cxx：控制流转换
  • opt_rename.cxx：SSA变量重命名、更新
  • opt_du.cxx：构建define-use信息
  • opt_etable.cxx：基于表达式的部分冗余删除
  • opt_estr.cxx：强度削弱
  • opt_ehoist.cxx：代码提升
  • opt_lftr2.cxx：线性代码测试、替换
  • opt_vn.cxx：基于值编号的完全冗余删除
  • opt_ltable.cxx：针对load的部分冗余删除
  • opt_stable.cxx：store Partial Redundancy Elimination 针对store的部分冗余删除
  • opt_bdce.cxx： Bitwise dead code elimination–针对结构体
  • opt_htable_emit.cxx: 从SSA转换回WHIRL中间表示

7 相关资料和文献

您可能也喜欢：
Open64 课程–全局标量优化(WOPT I) part II
Open64 课程–全局标量优化(WOPT II)
Open64 课程–全局标量优化(WOPT I) part 1
open64课程–过程间分析优化(IPA)
Open64编译器 5.0版本发布
无觅

相关文章：

]]> http://www.lingcc.com/2011/08/13/11685/feed/ 0 GCC几个选项学习 http://www.lingcc.com/2011/06/27/11679/ http://www.lingcc.com/2011/06/27/11679/#comments Mon, 27 Jun 2011 12:20:32 +0000 erlv http://www.lingcc.com/?p=11679 [...]
您可能也喜欢：
Gcc和Open64中的-fPIC选项
GCC中的pie和fpie选项
仔细端详GCC 4.6的新特性
Open64、LLVM、GCC源代码行数对比
GCC如何进出GIMPLE中间表示
无觅

相关文章：

]]> 最近研究了一把GCC的选项，比较有意思，选些出来，学习学习。编译器作为程序员的重要工具，GCC作为编译器中应用最广泛的，无不处处体现出贴心的设计和功能支持。

1 -dumpmachine

给出当前使用GCC的信息,在erlv的Debian AMD64上，结果如下。
关于GCC的这些字段是什么意思，请参考这篇博文：

$ gcc -dumpmachine
x86_64-linux-gnu

2 -xc

其实，-xc和 “-x c”等同。

  • x用于指定输入的程序的语言，如果使用该选项，GCC就不再根据文件的后缀名判断语言类型。 

3 -dM

不做实际的预处理，仅仅列出所有#define的宏,这些宏大部分与体系结构和GNU相关，或来自所包含的头文件。

#程序输出太长，这里就不列出了
$gcc  -E -dM hello.c

另外，还有一些-dCHARS的组合选项：

  • -dD:和-dM类似，不过仅仅包含头文件中定义的宏，不会输出预处理器中默认定义的宏，另外会将源程序代码也预处理输出。
  • -dN：和-dD类似，但仅输出定义的宏的名称，不输出宏的值。
  • -dI:给出#include的头文件，预计预处理的结果
  • -dU:和-dD类似，但仅仅输出那些在源码中需要展开的，或者其定义会被测试到的宏。 

4 -print-file-name=include

打印GCC默认搜索include头文件的路径

$ gcc -print-file-name=include
/usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.6.1/include

5 -isystem DIR

将DIR路径作为头文件搜索路径之一。搜索顺序: -I指定的文件夹 =》 -isystem指定的文件夹 =》 标准系统头文件夹。

6 -nostdinc/-nostdinc++

不要搜索标准系统头文件目录，仅搜索-I指定的路径。

7 -Wp/-Wa/-Wl

这三个分别用来指定传递给 预处理起、汇编器和链接器的参数。

  • -Wp,option 等价于 -Xpreprocessor option
  • -Wa,option 等价于 -Xassembler option
  • -Wl,option 等价于 -Xlinker option

8 -EL/-EB

为小尾端/大尾端系统编译代码。默认是小尾端

9 -DMACRO/-UMACRO

定义宏MACRO/撤销对宏MACRO的定义

10 -G num

将全局和静态对象的大小分割成小于num字节的数据放入bss端的小数据中，而非正常数据中。
默认的num的值为8.

由于MIPS在从符号得到地址时，需要先取出高16位，再取出低16位，做拼接得到最终地址，所以就需要两次访存操作。
当程序中大量使用静态和全局数据时，这种方式就会让程序变慢。
于是就有了利用GP寄存器进行优化的方法，即采用和GP寄存器做相对偏移的方式访存，以便降低访存次数。
关键问题是编译器和汇编器需要在编译时刻确定哪些变量可以使用GP寄存器访问。
通常的做法是让大小小于一定值的变量通过GP寄存器访问。

若num为 0表示将这一优化关闭。

11 -msym32/-mnosym32

不管采取何种ABI，都假设/不假设所有符号都是32位的值。
这一选项配合-mabi=64 和-mno-abicall时非常有用，因为可以通过假设都是32位数据生成更小巧更快的符号地址

12 -fdelete-null-pointer-checks/-fno-delete-null-pointer-checks

delete-null-pointer-checks是一种优化手段，通过全局的数据流分析来识别和删除所有对空指针的检测操作。
编译器假定对空指针的解引用会造成程序终止。但因为有些环境下，这一结论并不一定成立，而O2，O3和Os时会开启此优化。
因此GCC增加了选项-fno-delete-null-pointer-checks

13 -mcheck-zero-division/-mno-check-zero-division

当整数除0操作时，陷入/不陷入

14 -mabicalls/-mno-abicalls

生成/不生成适SVR4形式的动态对象代码，默认生成。

15 -mbranch-likely/-mno-branch-likely

使用/使用 branch likely 指令，不管所指定体系结构默认是否支持。
GCC默认会为支持branch likely指令的体系结构生成branch likely指令。

引入这类指令，是为了引入一种很大可能会发生跳转的指令，这样编译器就能充分的利用MIPS中的delay slot。

16 -fstack-protector

为可能的缓冲区溢出生成额外的检测代码。

17 -fstrict-overflow

允许编译器使用严格的有符号溢出规则。

18 -fconserve-stack

尽量减小对栈的使用。

19 参考

您可能也喜欢：
Gcc和Open64中的-fPIC选项
GCC中的pie和fpie选项
仔细端详GCC 4.6的新特性
Open64、LLVM、GCC源代码行数对比
GCC如何进出GIMPLE中间表示
无觅

相关文章：

]]> http://www.lingcc.com/2011/06/27/11679/feed/ 6 仔细端详GCC 4.6的新特性 http://www.lingcc.com/2011/03/28/11567/ http://www.lingcc.com/2011/03/28/11567/#comments Mon, 28 Mar 2011 09:24:23 +0000 erlv http://www.lingcc.com/?p=11567 [...]
您可能也喜欢：
GCC Internal 中文文档上线
GCC如何进出GIMPLE中间表示
GCC即将支持龙芯3A
Open64、LLVM、GCC源代码行数对比
GCC几个选项学习
无觅

相关文章：

]]> 去年3月GCC 4.5.0发布，而今，GCC刚刚正式发布了4.6版本。这个版本包含了很多的更新。

亮点：

  • 大大改进了过程间分析和链接时优化。正确性方面，编译了FIrefox，无疑是最有力的证明，但性能方面的评测没有，所以LTO是否真有性能不好说。不过从
  • Go语言进入了GCC的支持
  • 龙芯3A也支持了。
  • AVX支持了，但看样子，有点弱(没有自己调研过)。
  • 增加了128位浮点数支持，这个在科学计算领域应该很有用，X86和安腾系的芯片首先得益。
  • 另外，Phoronix刚刚发布了针对GCC4.5.2， 4.6RC2， LLVM2.9和DragonEgg的性能评测，结果看起来GCC4.6不是很给力。不清楚具体开了什么编译选项。

 

细节更新如下：

  • 更标准化的选项。含义不精确的选项被取缔，通过gcc命令传递给汇编器和链接器的选项，也通通需要加上指定的前缀，如-Wl,–as-needed.
  • 修正了一个GCC内部函数cproj和ISO C99标准不一致的地方，并做了优化，不过用户需要GLIBC 2.12及以后的版本才行。
  • 移除了模块间优化扩展，使用4.5中引入的LTO代替之。
  • 增加了采用LGPL协议的libquadmath数学库，这个库可以为32位x86，x86-64和安腾平台提供128浮点数的浮点运算支持。
  • 删除了一些老旧平台的支持。

优化方面的更新：

  • 增加猥琐级编译优化选项-ofast,这个选项除了打开-O3的所有优化外，还开启了所有能开启的优化，以获得更好的性能，如-ffast-mast优化
  • 改进链接时优化(LTO)：
    • 全局可扩展优化器已经足够稳定。打开LTO后会默认开启此优化。该优化器可以自动分割成几个并行的编译过程，可以用选项-flto=n指定并行编译进程个数。
    • 搞定了很多LTO的bug。打开LTO可以编译Firefox了。
    • 改进连接器插件
    • C++内联函数和虚表采取了更急进的私有化策略，以便更好的作过程间优化。
    • 改进内存试用
    • 将独立单元的静态构造和析构函数内联到一个单独函数中，以便加速大型C++程序的启动
    • 支持Ada语言
  • 过程间优化的改进
    • 已经为了LTO调优了过程间处理机制，获得了更好的扩展性。
    • 改进对const和pure函数的自动检测
    • 一些针对内联的改进
      • O2现在会开启部分内联。即，将函数分割成较热的路径和不热的路径。这样，就可以对热路径采用更激进的优化策略。
      • 改进对大的编译单元的扩展性。
      • 对回调的内联更激进
      • 改进对虚方法的内联，以及在开启-Os选项时针对C++程序的内联策略。
    • 加强IPA引用优化阶段 对 全局变量的使用/定义的检测，
    • 死函数地址优化
  • 增加-fstack-usage选项。编译器可以输出程序的栈使用信息

其他更新

  • 改进编译时间和内存占用。
  • 增加Go语言支持
  • 增加对avx的支持
  • 增加对龙芯3A的支持
您可能也喜欢：
GCC Internal 中文文档上线
GCC如何进出GIMPLE中间表示
GCC即将支持龙芯3A
Open64、LLVM、GCC源代码行数对比
GCC几个选项学习
无觅

相关文章：

]]> http://www.lingcc.com/2011/03/28/11567/feed/ 13 说说静态代码分析工具 http://www.lingcc.com/2010/11/04/11412/ http://www.lingcc.com/2010/11/04/11412/#comments Thu, 04 Nov 2010 14:30:59 +0000 erlv http://www.lingcc.com/?p=11412 您可能也喜欢： Open64、LLVM、GCC源代码行数对比 Open64课程—代码生成(CG) GCC几个选项学习 open64中的gcc前端 仔细端详GCC 4.6的新特性 无觅

相关文章：

]]> 昨天的360大战QQ相比各位都有领略了。双方都提到已将代码送交有关部门审查，或者从有关部门拿到了代码审查报告之类的。代码审查，光靠人看可不行，代码分析工具少不了。这是维基上关于静态代码分析的介绍。这个页面列出了很多静态代码分析工具，应该比较全了。碰巧Intel的博客发表了一篇文章。介绍ICC和一款商业代码分析工具的对比。这里就借花献佛，现读现卖。学习学习。这篇文章并不是简单的翻译Intel的博客，增加了很多概念性的和GCC的相关内容。

之所以称之为静态代码分析，是因为只是分析源代码或者生成的目标文件，并不实际运行源代码生成的文件。这个方向现在很热，因为程序越来越多，而越来越多的领域依赖计算机，代码的质量就成了关键。比如航天、国防、工业控制、金融等对安全性，稳定性要求很高的领域。

现在的静态代码分析几乎都是采用形式化的方法，所谓形式化，即使用类似数学推导的形式，运用数学的方法分析代码。当然也会包括一些经典的分析，比如使用memcpy要小心越界、操作字符串要小心之类的提醒。

虽然本质上，计算机只不过是个状态机，在不同的状态之间转换。但实际上，图灵爷早在1930年就证明确实没办法静态确定运行时程序所有的错误。所以，一切静态分析工具理论上都没办法找到所有问题。不过，聊胜于无。找到点总是有好处的。分析工具一般有模型检测、数据流分析、抽象解释模型等方式来实现静态分析。国内，中科院软件所和中国科学技术大学都有团队在做这个方向，其他高校不清楚。

编译器和静态代码分析工具都能检查代码中的潜在问题。但是编译器和其他工具区别很大。intel文章选取了notepad++这个应用程序的代码来测试intel C++编译器和PVS-studio分析器。notepad++用C++编写，代码量比较小，73000行。

ICC编译器的分析

一般的，编译器最重要的作用是生成可执行文件，所以对于词法语法的分析相对局部一些，即在检测错误时，前后查看的代码较少。这也是为了编译器的性能，因为还有很多的优化变换要做，所以编译器在词法语法分析上不能耗费太多时间。尤其是大的工程，代码量很大。编译要半天的时间时，5%的性能差距就会差十几分钟。

编译器在做完预处理后，就开始做词法语法分析，这就是程序分析的主要阶段。有的编译器，在生成抽象语法树(AST)时，会立即对抽象语法树处理，生成汇编。有的会做完整个函数、文件甚至整个程序之后，再做整体分析，生成汇编代码。Visual C++就是典型的第一类，因为它并不看重很多编译优化，更看重快速的程序分析和编译，不过程序员可以规定VC++报warning的级别。GCC和Open64偏向后者，其中Open64在没开过程间优化时，通常针对每个函数做处理，开了优化，就会对整个程序做分析。

编译器的这些区别就决定了能检测的错误的数量。而这错误的数量绝大多数和指定编译器分析代码的范围有关。比如intel文章作者就发现notepad++使用VC++ /w4（最高警告级别)编译不会报任何警告，使用Intel的C++编译器，开到/w5级别，发现了个潜在的问题：可能出错的强制类型转换(函数处理字符串而非字符，但传入的参数仅仅是指向字符的指针，并且会修改内存)。当然，作者也承认，除了这个错外，ICC还报了一些比较无聊的警告。

GCC的代码分析

GCC代码分析的输出可以通过控制警告输出实现，这里给出了所有和语言无关的警告选项。这里给出了C++语言相关的选项。GCC的 调几个说说：-Wall会给出所有用户可能需要仔细考虑的警告，比如字符做数组下标、注释里的格式不对、直接比较枚举类型等等；-Wextra会打开一些-Wall没有打开的警告选项。利用这两个选项，大的程序，应该够你折腾一段时间了：）。

第三方的静态代码分析器

这种工具并没有时间上苛刻的需求，因为不用像编译器那样需要频繁的运行。所以，这些分析工具通常会非常慢。所以你可以白天用编译器写代码，晚上用分析器检查代码。慢是能带来好处的，静态代码分析器可以将程序的抽象语法数保存、分析、转换，精确的分析，找到的问题更多，更准确。

文章作者使用PVS-studio分析了notepad++的代码。结果显示，这个工具很牛，能发现一些潜在问题，或者针对某些潜在问题给出警告。比如，找到memset函数，会提醒你可能溢出；发现一些不容易发现的无意义语句，如if-else走的分支完全一样，或者&&两边的操作数完全相同之类的警告。

问题：

虽然能帮助发现错误，但太敏感也不好。作者使用ICC做检测时，给出了439个警告和3139个注意。总的来说73000/3578=20,也就是说平均20行就有报一个问题，要想每个都好好分析，任重道远。而且仅仅有4个真正的问题。PVS-studio仅仅给出了10个警告，4个是真正的问题。看来还是专业才比较好。

您可能也喜欢：
Open64、LLVM、GCC源代码行数对比
Open64课程—代码生成(CG)
GCC几个选项学习
open64中的gcc前端
仔细端详GCC 4.6的新特性
无觅

相关文章：

]]> http://www.lingcc.com/2010/11/04/11412/feed/ 2