编译器的魔法：生成C代码的六点思考

在编译器开发中，我们经常需要将程序翻译成其他形式。相比直接生成汇编代码，C语言是一个更高层次的目标语言选择。生成C代码比手写C代码更安全------生成器可以避免许多未定义行为的陷阱。本文分享我在实践中总结的六个技巧。

1. 用静态内联函数实现数据抽象

早期学习C语言时，我们大量使用预处理器宏。后来才意识到，静态内联函数可以完全消除数据抽象的性能开销。

以WebAssembly内存访问为例：

c 复制代码

struct memory { uintptr_t base; uint64_t size; };
struct access { uint32_t addr; uint32_t len; };

#define static_inline \
  static inline __attribute__((always_inline))

static_inline void* write_ptr(struct memory m, struct access a) {
  BOUNDS_CHECK(m, a);
  char *base = __builtin_assume_aligned((char *) m.base_addr, 4096);
  return (void *) (base + a.addr);
}

static_inline 属性确保抽象成本完全消失。如果不使用内联，结构体可能会通过内存传递，尤其是在x64 ABI中返回结构体时。静态内联函数让我们无需担心这类性能瓶颈。

2. 避免隐式整数转换

C语言的默认整数转换规则很奇怪，比如将 uint8_t 提升为 signed int。生成C代码时，应该显式定义转换函数：

c 复制代码

static_inline uint32_t u8_to_u32(uint8_t x) { return x; }
static_inline int32_t s16_to_s32(int16_t x) { return x; }

配合 -Wconversion 编译选项，这种做法还能让生成的代码断言操作数类型正确。理想情况下，所有类型转换都在辅助函数中，生成的代码中没有任何强制转换。

3. 用意图明确的包装类型

在垃圾回收器Whippet中，对象有多种视角：绝对地址、页空间范围、对齐区域偏移等。如果都用 size_t 或 uintptr_t 表示，代码会很混乱。

解决方案是使用单成员结构体来区分不同概念：

c 复制代码

typedef struct gc_ref { uintptr_t value; } gc_ref;
typedef struct gc_edge { uintptr_t value; } gc_edge;

这种模式对编译器特别有用。在WebAssembly编译中，可以构建指针子类型森林：

c 复制代码

typedef struct anyref { uintptr_t value; } anyref;
typedef struct eqref { anyref p; } eqref;
typedef struct structref { eqref p; } structref;
typedef struct type_0ref { structref p; } type_0ref;

这样类型就能从源语言传递到目标语言，编译器还能自动生成类型检查的向上转换。

4. 不要害怕 memcpy

WebAssembly的线性内存访问不一定对齐，所以不能简单地将地址转换为 int32_t* 并解引用。正确做法是：

c 复制代码

memcpy(&i32, addr, sizeof(int32_t));

信任编译器------它会在可能的情况下直接生成非对齐加载指令。无需多言！

5. 手动寄存器分配处理ABI和尾调用

虽然GCC终于支持了 __attribute__((musttail))，但编译WebAssembly时可能遇到30个参数或返回值的函数。我不相信C编译器能可靠地处理这种情况的栈参数调整。

解决方案：只在寄存器中传递前n个值，其余使用全局变量。这样不需要栈，因为可以在函数序言中将它们加载到局部变量。

这种方法还巧妙地支持了多返回值：为每种函数类型分配足够的全局变量，让函数尾声将"多余"的返回值存储到全局变量中，调用者在调用后立即重新加载。

6. 生成C代码的局限性

生成C代码是一个局部最优解：你获得了GCC或Clang的工业级指令选择和寄存器分配，不需要实现许多窥孔优化，还能链接到可能内联的C运行时例程。

但也有缺点：

无法控制栈：不知道函数需要多少栈空间，无法合理扩展程序栈，无法精确枚举栈中的嵌入指针，更无法切片栈来捕获定界延续
缺少边表支持：无法实现零成本异常
源码级调试困难：不知道如何在生成C代码时嵌入DWARF调试信息

至于为什么不用Rust？如果源语言有显式生命周期，我会考虑生成Rust代码，因为可以机器检查输出与输入具有相同保证。但对于没有复杂生命周期的语言，Rust的优势有限：更少的隐式转换，但尾调用支持不成熟，编译时间更长......权衡之下，C语言仍是合理选择。

总结

没有什么是完美的，但了解这些技巧能让你的C代码生成之旅更顺畅。对我而言，一旦生成的C代码通过类型检查，它就能正常工作------几乎不需要调试。这不是编程的常态，但能遇到就值得珍惜。

Happy hacking!