LLVM IR 生成

一、内存 SSA

llvm 是 SSA 形式的，但是在没有经过 mem2reg 的时候，SSA 是内存形式的，也就是说，对于每个变量，只要在定义他的时候，为他在内存中划分空间存入，在使用他的时候在取出来，这样就可以达到 SSA 的效果。这是因为 SSA 只要求我们不能改变一个已经定义的值，改变内存的内容显然并不违法 SSA。

这会导致当我们提到（也就是查询）一个局部变量的时候，其实是从符号表中取出来的是它的指针，这个过程一般发生在 LVal。一般我们会对变量干两件事情，读变量和写变量和做实参。对于读变量，一般发生在 LVal 作为 PrimaryExp 的时候发生，此时需要在 PrimaryExp 中对其进行 Load，而写变量一般发生在 LVal 在 AssignStmt 和 InStmt 中，只需要用 Store 将其写入即可。做实参要单独挑出来讲，是因为它的逻辑是与 C 需要保持一致的，他是有指针类型的，这就要求我们对他进行单独的处理。这就是内存式 SSA 的基本逻辑。

错误处理

一、总论

错误处理和解析生成中间代码的过程是类似的，都可以看做是一个语法制导翻译的过程。对于遍历出的节点，触发不同的动作符号，这些动作符号在错误处理中用于检测错误，而在生成中间代码生成中，这些动作符号用于生成中间代码。

错误处理会遍历语法生成树，CST 的每个节点都实现了 check 方法用于检查有没有错误。

Pansy Parser

这里是 Pansy 编译器的 parser

具体语法树

Parser 的目的是为了根据语法获得一个具体语法树（Concrete Syntax Tree，CST）。这棵语法树的非叶子节点是各个语法成分，而叶子节点则是 Token （或者说包含 Token）。强调这个是因为我没有意识到可以将 Token 与其他语法成分等量齐观。

在文法中，我们约定非叶子节点采用首字母大写的驼峰命名法，比如 CompUnit，而对于叶子节点，我们采用全大写的形式，比如 IDENFR 。

代码优化

1 个人信息

2 总论

我个人认为，优化分为两类，一类是分析型优化，这种类型的优化并不会改变 llvm ir 的结构，所以也不会有实际的优化效果，但是它们分析出来的信息，会去指导加工型优化的进行。另一种是加工型优化，这种优化会真正改变 llvm ir 的结构，达到优化的目的。

DFS 中边的分类

在无向图中，有两种边：

• 树边：指出现在深度优先树中的边。
• 后向边：两顶点有祖先后代关系的非树边。这个后向边的定义其实叫做非横向边更好，因为“有祖先后代关系”的意思就是这个边的端点不可能在深度优先树上是兄弟关系。

也就是说，只要是非树边，就一定是后向边，这个我粗略思考，感觉可以用括号化定理证明。

在有向图中，有四种边：

一、总论

第一次当产品经理，以为就很简单，甚至可以很摸鱼的干完，但是事实并不是这样的，从结果来看，似乎并不能说，因为有了我，团队得到了一些其他团队所不具有的优势，并且并不需要付出相应的代价。

应该这么说，我天生对于“条理和系统”的追求让我们的团队合作确实相比于其他团队要更加有条不紊的进行，在项目架构上没有出现大幅度修改，我“前瞻”的习惯也让团队没有遇到过十分紧急的技术难题，我良好的记忆力和文档更新速度，也让团队交流的效率大大提高。

但是我对于设计风格和设计需求的“独裁”确实在一定程度上损害了团队的表现。在设计风格方面，作为一个美术生，我显然自视甚高，不过其实我是一个十分没有才华的美术生，所以导致我并没有办法托举整个团队的审美。而在设计需求方面，我没啥“独裁”的欲念，不过我实在是太善于表达，导致组员确实没法正常表达完整观点（当然，可能是他们不在乎），这就导致有有一些需求是没有覆盖到，从后面的经验来看，如果需求没有覆盖全，那么将是致命的。

写这个文章的目的也是为了给以后的工程实践积累一些经验，同时为假期的预习指明一些道路。