通用中间语言翻译模块¶

通用中间语言翻译模块是莲花Lian多语言分析能力的基础，其目标是将不同源语言的代码翻译为与语言无关的统一的中间表示GIR（Generic Intermediate Representation）。通过GIR对代码的抽象，后续的语义分析（如控制流分析、数据流分析、指针分析、污点分析等）能够彻底脱离具体语言的语法限制与类型系统束缚，而实现统一的程序分析。

GIR重要设计理念是，尽管语法千差万别，但行为层面的语义结构具有高度的共性。GIR正是这种一致性的具象化表达。GIR对新语言的支持具有重要意义，将传统上需为每种语言重构整套分析算法的方法，简化为仅需实现一个轻量级的前端翻译器，将源语言映射至GIR。基于这种设计，莲花系统已成功兼容C、Java、Python、JavaScript、PHP、TypeScript、Go等多种语言。

1 现有中间语言的局限性¶

在程序分析领域，已有多种成熟的中间表示，但在处理多语言时，仍面临显著障碍：

LLVM IR：LLVM IR侧重于底层编译优化与机器码生成，其语义高度依赖静态类型信息。LLVM IR指令构建在类型完备的前提下，这使其在处理C/C++时效率极高，易于翻译为底层代码。但是在处理Python、JavaScript等动态语言时，由于类型往往是分析的结果而非前提，使得将动态语言有效翻译为LLVM IR极具挑战。

同时，LLVM IR会将上层指令（如字段访问、数组元素访问等）降级为基于地址的指令（如getelementptr指令），导致字段名（field）、索引（index）等高层语义信息丢失；此外，动态语言支持对属性的动态添加，这导致这种扁平化的分析方式对于语义信息的分析和程序行为的理解极其不利。
WALA IR：虽然WALA IR提供了一定的语言抽象，但其构建严重依赖一系列前置分析结果（如控制流图构造、SSA转换及类型分析）。这意味着每新增一门语言，开发者都必须重新实现这些前置的控制流和SSA等复杂分析流水线，这导致工程维护成本极高，阻碍快速扩展。
Truffle AST：Truffle AST设计理念是面向运行时执行，其节点语义紧密围绕运行时执行设计。其设计与运行时执行模型深度绑定，导致其难以为全程序静态分析提供一个高层且统一的表达。

因此，已有的中间语言并不适用于莲花程序分析框架的场景。针对这一现状，GIR被设计为一种高层、语言无关且面向静态分析的中间表示。

2 通用中间语言GIR的设计哲学¶

GIR的设计核心是不以类型为建模前提，转而以程序行为语义为抽象核心。因此，GIR不预设任何特定语言的特性，基于语言行为语义的共性，实现对静态与动态类型语言的兼容。

主流编程语言在行为层面共享一套核心结构：

程序由模块与函数组成；
函数内部通过变量声明与作用域管理状态；
数据通过赋值、读取与传递产生流向；
执行逻辑由条件与循环驱动；
而面向对象范式则进一步引入了类、字段与方法的维度。

GIR针对这些共性定义了79条基础指令，精准覆盖了程序的核心语义单元。这些指令命名直观，且每条指令语义单一、边界清晰，便于后续分析建立精确的语义关系。同时，语言特有的语法糖由前端展开为多条基础GIR指令的组合。

值得注意的是，GIR并不追求极致的指令精简，而是追求表达的准确性，以便后续分析算法能直接建立精确的语义关联。

对于差异化处理，GIR并不试图强行抹平语言间的特性差异（如JS的原型链或Python的动态属性注入）。它的定位是忠实记录“发生了什么行为”，而将“该行为在特定语言中的具体含义”交给语言差异兼容模块去处理。这种职责解耦确保了GIR结构的长期稳定，使得核心分析算法能保持通用，而语言特有的逻辑则以插件形式灵活叠加。

3 GIR前端¶

GIR前端采用自上而下的翻译流程：

首先，利用tree-sitter将源代码解析为语法树（通常视为AST，Abstract Syntax Tree）；
其次，进行语义映射，由lang_parser.py调度具体语言的解析器，从AST根节点开始自上而下递归遍历，将每个语法节点递归映射为一条或多条原子性的GIR指令。

在此过程中，前端翻译器无需执行复杂的控制流计算或SSA变换，只需保留变量声明、作用域切换、函数调用以及显式数据流关系等原始信息。这种设计极大地降低了接入新语言的门槛，避免了在翻译阶段因过早引入假设而导致的分析失真。

最终，生成的GIR指令作为标准化、语言无关的程序代码表示，驱动莲花系统的所有后续分析。无论是复杂的指针指向还是敏感的数据追踪，分析的对象始终是稳定、统一的GIR，这正是莲花系统实现多语言高精度分析与工程可持续发展的关键。