Golang 编译器代码浅析
  • 0. Golang 编译器代码浅析
  • 1. golang 编译器 - 前言
    • 1.1 编译器简介
    • 1.2 Golang 编译器
    • 1.3 Go 语言版本
    • 1.4 项目设置
    • 1.5 约定
    • 1.6 写作目的
  • 2. golang 编译器 - 词法分析
    • 2.1 简介
    • 2.2 代码结构
    • 2.3 处理字符
    • 2.4 扫描Token
    • 2.5 总结
  • 3.a 语法分析理论知识
    • 3A.1 语法分析简介
    • 3A.2 文法
    • 3A.3 语法解析
    • 3A.3.1 自顶向下(Top-Down)
    • 3A.3.2 自顶向下 - 递归下降
    • 3A.3.3 自顶向下 - LL(1)文法
    • 3A.3.4 自底向上(Bottom-Up)
    • 3A.3.5 自底向上 - LR(0)项集及SLR预测表
    • 3A.3.6 自底向上 - LR(1)、LALR
    • 3A.4 语法分析工具
    • 3A.5 总结
  • 3B. golang 编译器 - 语法分析
    • 3B.1 简介
    • 3B.2 代码结构
    • 3B.3 数据结构
    • 3B.4 构造语法树
    • 3B.5 Unit Test及AST可视化
  • 4. Golang 编译器 - 类型检查
    • 4.1 简介
    • 4.2 代码结构
    • 4.3 符号解析
    • 4.4.1 数据结构 - 作用域
    • 4.4.2 数据结构 - Package
    • 4.4.3 数据结构 - Object 对象
    • 4.4.4-1 类型数据结构 - 简介
    • 4.4.4-2 类型接口
    • 4.4.4-3 基础类型
    • 4.4.4-4 内置复合类型
    • 4.4.4-5 Struct 类型
    • 4.4.4-6 Interface 类型
    • 4.4.4-7 Named 类型
    • 4.4.4-8 Tuple 类型
    • 4.4.4-9 Sum 类型
    • 4.4.4-10 Function & Method 类型
    • 4.4.4-11 泛型类型
    • 4.4.4-12 类型的等价规则
    • 4.4.4-13 类型的比较规则
    • 4.4.4-14 总结
    • 4.4.5 类型检查器
    • 4.4.6 总结
    • 4.5.1 类型检查逻辑 - 包加载器
    • 4.5.2 类型检查逻辑 - 初始化
    • 4.5.2-1 全局作用域
    • 4.5.2-2 类型检查器
    • 4.5.3 类型检查逻辑 - 流程分析
    • 4.5.3-1.1 总体流程
    • 4.5.3-1.2 类型检查准备工作
    • 4.5.3-1.3 类型检查核心逻辑
    • 4.5.3-1.3a 总体介绍
    • 4.5.3-1.3b 类型表达式的类型检查
    • 4.5.3-1.3c 求值表达式的类型检查
    • 4.5.3-1.3d 类型兼容性检查
    • 4.5.3-1.3e 处理delayed队列
    • 4.5.3-1.4 构建初始化顺序
    • 4.5.3-1.5 总结
    • 4.5.3-2 特定问题分析
    • 4.5.3-2a 对象循环依赖检查
    • 4.5.3-2b 方法与属性查找
    • 4.5.3-2c Underlying Type
    • 4.6 如何测试
    • 4.7 总结
  • 5. Golang 编译器 - IR Tree
    • 5.1 简介
    • 5.2 代码结构
    • 5.3 数据结构
    • 5.4 处理逻辑
    • 5.5 编译日志
    • 5.6 Unit Test
    • 5.7 总结
  • 6. golang 编译器 - 初始化任务
    • 6.1 简介
    • 6.2 代码结构
    • 6.3 总体逻辑
    • 6.4 赋值语句
    • 6.5 编译日志
    • 6.6 Unit Test
    • 6.7 总结
  • 7. golang 编译器 - 清除无效代码
    • 7.1 简介
    • 7.2 处理逻辑
    • 7.3 Unit Test
  • 8. golang 编译器 - Inline
    • 8.1 简介
    • 8.2 Inline的问题
    • 8.3 代码结构
    • 8.4 处理逻辑
    • 8.4.1 遍历调用链
    • 8.4.2 内联判断
    • 8.4.3 内联操作
    • 8.4.4 编译日志
    • 8.4.5 Unit Test
    • 8.4.6 总结
  • 9. golang 编译器 - 逃逸分析
    • 9.1 什么是逃逸分析
    • 9.2 Go 的逃逸分析
    • 9.3 算法思路
    • 9.4 代码结构
    • 9.5 处理逻辑
    • 9.5.1总体逻辑
    • 9.5.2 数据结构
    • 9.5.3 构建数据流有向图
    • 9.5.4 逃逸分析
    • 9.6 编译日志
    • 9.7 Unit Test
    • 9.8 总结
  • 10. golang 编译器 - 函数编译及导出
    • 10.1 简介
    • 10.2 编译函数
    • 10.2.1 SSA
    • 10.2.2 ABI
    • 10.2.3 并发控制
    • 10.3 导出对象文件
    • 10.4 总结
  • 11. Golang 编译器 - 写在最后
由 GitBook 提供支持
在本页

这有帮助吗?

  1. 8. golang 编译器 - Inline

8.4.2 内联判断

整个内联功能可以通过编译参数 -l 来禁止,对于某个特定函数,也可以通过编译命令 go:noinline 来禁止内联。除此之外,还有一些特定的情况下函数不能内联,例如函数体为空,或者函数包含一些特定的编译命令例如 go:cgo_unsafe_args 等。

除了这些明确的场景,一个函数能否内联取决于该函数的复杂度,前文中提到,函数调用对小函数影响更大,因此如何衡量函数的大小及复杂度,是编译器需要量化的事情。该逻辑由结构体 hairyVisitor 驱动:

type hairyVisitor struct {
    // 内联“预算”,起始值为 80, 由常量 inlineMaxBudget 定义,函数体内各种操作都会有对应的“代价(cost)”,总体“代价”超过“预算”的话,那么该函数就会由于太复杂而无法内联
    budget int32
    // 保存不能内联的理由
    reason string
    // 方法调用的开销,默认为 57, 由常量 inlineExtraCallCost 定义
    extraCallCost int32
    // 用来记录当前函数的局部变量,函数内联时需要使用
    usedLocals ir.NameSet
    // 遍历函数并进行复杂度计算,实际为方法 hairyVisitor.doNode()
    do func(ir.Node) bool
}

编译器定义了一个“内联代价(Inline Cost)”来表达函数复杂度,内联代价与函数 AST 的节点数目正相关,每个子节点的 cost 为 1, 如果该节点还需要额外的操作,则还需要减掉对应的Cost, 例如函数调用的 Cost 是 57, 由常量 inlineExtraCallCost 定义;内联总代价小于 80 的函数可以内联,该数字被称为函数的“内联预算(Budget)”,由常量 inlineMaxBudget 定义。

计算内联代价的方法是 hairyVisitor.doNode(), 该方法对函数的 AST(IR Tree) 进行深度优先(DFS)遍历,并从“内联预算(budget 字段)”中减掉函数体的各种“代价(cost)”,如果最终预算还有盈余,则函数可被内联。例如下列函数:

func B() {
    println("B")
    println("B")
}

// go:noinline
func C() {
    println("C")
}

func A() {
    println("A")
    C()
}

对于函数 B,语句 println("B") 总体的代价是 2, 因此整个函数的代价便是 4, 该函数没有用完内联预算,因此是可以内联的。而对于函数 A,其内联代价的计算如下:

Cost(A) = 2 + 2 + 57 = 61

2: 语句 println("A") 的代价

2: 语句 C() 本身的代价

57: 由于函数 C 无法内联,所以需要减去一个 extraCallCost, 默认为 57

A 仍然可以内联,但同时可以发现,如果 A 调用了两个以上不可内联的函数的话,那么他就会耗尽“预算”而无法内联了。

归总起来,判断函数能否内联的逻辑封装在函数 CanInline 中,精简代码之后其总体逻辑如下:

func CanInline(fn *ir.Func) {
    // Part 1: 判断各种特定情况,
    // If marked "go:noinline", don't inline
    if fn.Pragma&ir.Noinline != 0 {
        reason = "marked go:noinline"
        return
    }
    // 省略判断其它各种情况的代码

    // Part 2: 根据函数的大小判断能否内联
    visitor := hairyVisitor{
        budget:        inlineMaxBudget,
        extraCallCost: cc,
    }
    if visitor.tooHairy(fn) {
        reason = visitor.reason
        return
    }

    // Part 3: 对于可以内联的函数,创建内联节点。该节点在后面内联操作时使用
    n.Func.Inl = &ir.Inline{
        Cost: inlineMaxBudget - visitor.budget,
        Dcl:  pruneUnusedAutos(n.Defn.(*ir.Func).Dcl, &visitor),
        Body: inlcopylist(fn.Body),
    }
}

注意最后一部分逻辑,对于可以内联的函数, CanInline 会为该函数创建一个 ir.Inline 对象。

上一页8.4.1 遍历调用链下一页8.4.3 内联操作

最后更新于3年前

这有帮助吗?