llvm后端不直接支持可变参数函数，仅将ir中已有的@llvm.va_start等intrinsic映射到目标平台abi；语义由前端生成ir决定，后端依callingconv适配va_list布局，并由lowervaarg处理va_arg指令。
LLVM后端本身不直接“支持”可变参数函数——它只负责把 IR 中已有的 @llvm.va_start、@llvm.va_copy、@llvm.va_end 和 va_arg 指令/调用，正确映射到目标平台的寄存器分配、栈布局和调用约定上。真正的可变参数语义由前端（如 Clang）生成 IR 时决定，后端只需忠实实现 ABI 规则。
可变参数在 IR 层就已固化为特定 intrinsic 调用
Clang 等前端遇到 printf(const char*, ...) 这类签名时，会显式插入：
call void @llvm.va_start(ptr %ap)-
%arg = va_arg ptr %ap, i32（注意：这是指令，不是调用） call void @llvm.va_copy(ptr %aq, ptr %ap)call void @llvm.va_end(ptr %ap)
后端无需识别“...”语法，也不解析参数个数或类型；它只处理这些已生成的 IR 元素。如果 IR 里没出现 @llvm.va_*，后端完全感知不到可变参数的存在。
后端必须在 CallingConv 描述中适配 va_list 的 ABI 表示
不同平台对 va_list 的底层定义差异极大：
- x86-64 System V：
va_list是结构体{ char* gp_offset; char* fp_offset; char* overflow_arg_area; char* reg_save_area; }，后端需确保@llvm.va_start初始化这四个字段 - AArch64：
va_list是单个指针，指向一个包含整数/浮点寄存器索引和栈偏移的上下文区 - Windows x64：
va_list是四字段结构，但字段含义和初始化逻辑与 System V 不兼容
这意味着你必须在 TableGen 文件（如 ARMCallingConv.td）中为每种调用约定单独定义 CCIfType + CCAssignToReg 或 CCAssignToStack 规则，并覆盖 CCState::AnalyzeFormalArguments 的行为，让 @llvm.va_start 的参数能被正确解包并写入 va_list 对象内存布局。
va_arg 指令的代码生成依赖 TargetLowering
va_arg 是一条 IR 指令，不是函数调用，因此不走 CallLowering 流程，而是由 TargetLowering::LowerVAARG 处理。这个函数要完成三件事：
- 从
va_list指针读取当前整数/浮点寄存器索引和栈偏移 - 根据参数类型（
i32、double、struct）决定是 load 寄存器还是 load 栈地址 - 更新
va_list内部状态（例如递增gp_offset），并返回新值
常见坑：漏掉对 va_list 的更新，导致连续两次 va_arg 取到同一参数；或未按 ABI 对齐要求访问栈（如 AArch64 要求 16 字节对齐）。
测试时容易忽略的边界情况
光让简单 printf("%d", 42) 过掉远远不够。真正暴露问题的是：
- 混合整数与浮点参数（
printf("%d %f", 1, 2.0)）→ 检查 GP/FP 寄存器计数是否独立维护 - 大结构体作为可变参数（
struct { int a,b,c,d; } s; func(s)）→ 检查是否正确降级为栈传递并更新overflow_arg_area - 嵌套
va_copy→ 验证复制后的va_list是否拥有独立的寄存器索引和栈偏移 - 函数返回前未调用
@llvm.va_end→ 后端应允许空实现（多数平台无副作用），但不能崩溃或误优化
这些 case 在 TableGen 规则里很难覆盖全，最终依赖手写 C++ 的 CCState 子类和 LowerVAARG 实现——这也是为什么几乎所有成熟后端（X86、ARM、RISCV）都选择复用 LLVM 提供的通用 CCState 框架，而非重写整套逻辑。
