target datalayout 是 llvm ir 模块中必须解析的硬约束，由短横线分隔的键值对组成，定义字节序（e/e）、目标格式（m:e/m:o）、整型/浮点对齐（in:m/fn:m）、地址空间指针（pn:m:l）、原生宽度（n...）和栈对齐（s...）等规则，直接影响内存布局计算与跨平台abi兼容性。
target datalayout 字符串不是“配置项”也不是“注释”，它是 LLVM IR 模块中**必须被解析并用于内存布局决策的硬约束**。它直接影响 getelementptr 计算、结构体字段偏移、指针对齐、alloca 对齐等行为。不理解它，就无法准确预测 IR 到机器码的内存布局，尤其在跨平台或手写 IR 时极易出错。
data layout 字符串由哪些部分组成
它是一串用短横线 - 分隔的键值对，每个片段描述一类布局规则。常见片段包括：
-
e或E：小端（e）或大端（E）字节序 -
m:e或m:o：目标文件格式，e表示 ELF，o表示 Mach-O -
iN:M：N 位整数类型（如i32）的自然对齐为 M 位（如i32:32表示 4 字节对齐） -
fN:M：N 位浮点类型的对齐要求（如f64:64） -
pN:M:L：第 N 个地址空间（p270中的 270 是地址空间 ID）的指针大小、对齐、ABI 寻址宽度（如p270:32:32表示该地址空间下指针占 32 位、32 位对齐） -
n8:16:32:64：支持的原生整数宽度集合（影响alloca默认对齐和向量化选择） -
SN：栈帧自然对齐（如S128表示栈上分配默认 16 字节对齐）
注意：p 段中的地址空间编号（如 p270）是 LLVM 内部约定，**不对应硬件地址空间**，而是方言（如 NVVM、SPIR-V）自定义地址空间的索引；n 段只影响优化器决策，不改变类型大小。
为什么不同平台的 data layout 差异很大
因为底层 ABI（应用二进制接口）强制要求不同。例如：
- x86_64 Linux（ELF）常用：
e-m:e-i64:64-f80:128-n8:16:32:64-S128 - macOS（Mach-O）常用：
e-m:o-i64:64-f80:128-n8:16:32:64-S128（仅m:o不同） - Aarch64 Android：
e-m:e-i8:8-i16:16-i32:32-i64:64-f32:32-f64:64-a:0:128-n32-S64（含a:0:128表示向量寄存器对齐）
关键差异点：
-
m:后缀决定符号可见性与重定位方式（ELF vs Mach-O） -
n列表影响alloca的默认对齐——若漏掉n32，而代码用了i32，某些后端可能降级为 8 字节对齐，导致 SSE 指令崩溃 -
S值过小（如S32）会导致栈上double或__m128被错误对齐，触发 SIGBUS
手写或修改 data layout 时最容易踩的坑
直接改字符串而不校验后果，等于绕过 LLVM 的布局验证机制。典型错误：
- 删掉
p270:32:32却保留addrspace(270)的指针类型 →llc报错：Invalid data layout: missing spec for address space 270 - 把
i64:64改成i64:32，但没同步改n列表 → 结构体中i64字段偏移错乱，getelementptr算出负偏移 - 在 Windows x64 上误用 Linux 的 layout（如漏掉
-S256）→__m256栈变量未按 32 字节对齐，AVX 指令触发 general protection fault - 认为
f80:128只影响 x87 → 实际上它也控制long double在结构体内的填充，改错会导致 ABI 不兼容
真正安全的做法是：用 llvm-config --host-target 查当前默认 triple，再用 llc -mtriple=... --print-datlayout 输出真实 layout，而不是凭经验拼接。
最常被忽略的一点：DataLayout 不仅作用于模块全局，还会被 llvm::DataLayout 对象缓存并参与所有 getTypeStoreSize / getStructLayout 查询——一旦模块中 layout 字符串非法或缺失，后续所有内存布局计算都不可信，且错误往往延迟到 codegen 阶段才暴露。
