align是硬约束而非提示，.ll中load/store/alloca的align值必须与target datalayout规定的ABI对齐一致，否则导致未定义行为或后端报错；其来源包括源码显式对齐、结构体成员自然对齐或Clang根据datalayout推导的默认值。
align 属性直接决定指针访问的对齐方式，它不是可选提示，而是 IR 生成和后端代码生成时的硬约束；不匹配目标平台 target datalayout 中规定的对齐规则，会导致未定义行为或后端拒绝生成合法汇编。
怎么看 .ll 文件里的 align 值
在 .ll 文件中，load、store 和 alloca 指令常带 align 参数，例如：
%0 = load i32, i32* %ptr, align 4
这个 align 4 表示该次内存访问要求地址按 4 字节对齐。它的来源可能是：
- 源码中变量声明带
__attribute__((aligned(4)))或_Alignas(4) - 结构体成员自然对齐（如
i64字段默认要求 8 字节对齐） - Clang 根据
target datalayout推导出的 ABI 默认对齐（比如i32在大多数平台默认align 4）
注意：即使你没显式写 align，IR 生成器也会自动插入一个值——省略不等于无约束。
align 必须和 target datalayout 一致
target datalayout 字符串（出现在 .ll 文件头部）定义了整个模块的对齐策略。例如：
target datalayout = "e-m:o-i64:64-f80:128-n8:16:32:64-S128"
其中 i64:64:64 表示：i64 类型的最小对齐（ABI 对齐）是 64 位（即 8 字节），首选对齐也是 8 字节。那么所有 i64* 的 load/store，其 align 至少得是 8，否则后端可能报错或降级为非原子访问。
常见不一致现象：
-
store i64, i64* %p, align 1—— 明确违反i64:64:64，LLVM 后端（如llc）可能拒绝编译或静默修正 -
alloca [10 x i32], align 1—— 即使数组本身没对齐需求，但若后续用getelementptr计算出的i64*地址被load i64，而该地址实际只满足align 1，就触发未定义行为
结构体/数组里的对齐怎么推导
LLVM 不直接记录字段偏移，而是靠 getelementptr + target datalayout 共同隐式决定。例如：
%S = type { i8, i64 }在 e-m:o-i64:64-f80:128-n8:16:32:64-S128 下，i64 成员必须 8 字节对齐，因此 %S 总大小会被填充到 16 字节，首成员 i8 占 1 字节，后面跟 7 字节 padding，再放 i64。
此时若你写：
%p = alloca %S, align 1
那后续通过 getelementptr %S, %S* %p, i32 0, i32 1 得到的 i64* 指针，其地址可能不满足 align 8，哪怕你手动 load i64, align 8，也会出问题——因为底层内存根本没按 8 字节对齐分配。
所以关键点是：alloca 的 align 要 ≥ 结构体内最大对齐字段所需值，不能只看类型声明，得看布局结果。
容易被忽略的陷阱
最常踩的坑不是 align 写得太小，而是「以为写了就安全」：
-
align是单次访问约束，不保证整块内存连续满足——比如alloca [100 x i8], align 16只确保起始地址 16 字节对齐，不代表第 16 字节处的i64*就一定对齐（除非你确认索引是 16 的倍数） - 跨函数传递指针时，调用者写的
align不会自动传播给被调函数；被调函数里load的align需独立声明，且必须与实际内存布局兼容 -
getelementptr inbounds不检查运行时对齐，只做编译期地址计算；错误的align在 IR 层不会报错，但会在llc或运行时暴露
真正要看齐不齐，得把 target datalayout、alloca 的 align、GEP 索引、最终访问类型四者串起来算——少一环都可能掉进硬件异常或性能陷阱。
