编译器的结构
- 重要的系统软件
- 识别符合语法和非法的程序
- 生成正确且高效的代码
- 分析部分(前端front end)
- 词法分析,生成词素(lexeme)
- 语法分析,生成语法树
- 语义分析,收集类型信息,进行语义检查
- 中间代码生成,生成intermediate representation(IR)
- 综合部分(后端back end)
- 代码优化,机器无关优化,生成优化后的IR
- 代码生成,生成目标代码
静态分析
- 静态分析:不执行程序代码,推导程序的行为,分析程序的性质。
- 控制流(control flow):程序执行的流程
- 数据量(data flow):数据在控制流上的传递
- 根据分析控制流和数据流,我们可以知道更多关于程序的性质(properties)
- 根据这些性质优化代码
过程内分析和过程间分析
- 过程内分析(intra-procedural analysis)
- 仅在函数内部进行分析
- 过程间分析(inter-procedural analysis)
- 考虑函数调用时参数传递和返回值的数据流和控制流
- 为什么过程间分析是个问题?
- 需要通过数据流分析得知 i 的具体类型,才知道i.foo()调用的是哪个foo()
- 根据 i 的具体类型,产生了新的控制流,i.foo(),分析继续
- 过程间分析需要同时分析控制流和数据流—联合求解,比较复杂分析A.foo(),还是B.foo()?
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19type I interface{
foo()
}
type A struct{}
type B struct{}
func (a *A) foo() {
...
}
func (b *B) foo() {
...
}
func bar() {
...
i.foo()
}
编译器优化
- 为什么做编译器优化
- 用户无感知,重新编译即可获得性能效益
- 通用性优化
- 现状
- 采用的优化少
- 编译时间短,没有进行复杂的代码分析和优化
- 编译优化的思路
- 场景:面向后端长期执行任务
- Tradeoff:用编译时间换取更高效的机器码
- Best mode
- 函数内联
- 逃逸分析
- 默认栈大小调整
- 边界检查消除
- 循环展开
- ……
函数内联(Inling)
- 内联:将被调用函数的函数体(callee)的副本替换到调用位置(caller)上,同时重写代码及反映参数的绑定
- 优点
- 消除函数调用开销,例如传递参数、保存寄存器等
- 将过程间分析转化为过程内分析,帮助其他优化,例如逃逸分析
- 缺点
- 函数体变大,instruction cache(icache)不友好
- 编译生成的Go镜像变大
- 函数内联在大多数情况下是正向优化
- 内联策略
- 调用和被调函数的规模
- …
Beast Mode
- Go函数内联受到的限制较多
- 语言特性,例如interface,defer等,限制了函数内联
- 内联策略非常保守
- Beast mode:调整函数内联的策略,使更多函数被内联
- 降低函数调用的开销
- 增加了其他优化的机会:逃逸分析
- 开销
- Go镜像增加~10%
- 编译时间增加
逃逸分析
- 逃逸分析:分析代码中指针的动态作用域:指针在何处可以被访问
- 大致思路
- 从对象分配处出发,沿着控制流,观察对象的数据流
- 若发现指针p在当前作用域s:
- 作为参数传递给其他函数
- 传递给全局变量
- 传递给其他的goroutine
- 传递给已逃逸的指针指向的对象
- 则指针p指向的对象逃逸出s,反之则没有逃逸出s
- Beast mode:函数内联拓展了函数边界,更多对象不逃逸
- 优化:未逃逸的对象可以在栈上分配
- 对象在栈上分配和回收很快:移动sp
- 减少在heap上的分配,降低GC负担