LLVM IR中load/store通过指针间接访问内存，类型、对齐、初始化必须严格匹配，否则导致未定义行为或运行时崩溃；指针须由alloca或getelementptr生成，不可直接使用地址常量。
LLVM IR 的 load 和 store 不直接操作物理地址，而是通过指针值（pointer value）间接访问内存；写错类型、对齐或未初始化指针会立即导致未定义行为（UB），不是报错，是静默崩溃或错误结果。
load / store 的参数必须严格匹配指针所指类型
LLVM 是强类型 IR，load 读出的值类型必须和指针的 pointee 类型一致。比如 i32* %ptr 只能配 load i32, i32* %ptr，不能写成 load i64, i32* %ptr —— 这在解析阶段就会被 llc 或 opt 拒绝，报错类似：invalid load type: expected 'i32', got 'i64'。
常见误用场景：
- 把
alloca i32得到的i32*拿去load double（类型不兼容） - 用
getelementptr算出地址后忘了改指针类型（例如 GEP 返回i8*，但直接拿去load i32） - 对
void*（即i8*）做load而不先用bitcast转型
store 必须确保目标地址可写且对齐
store 不检查地址合法性。向未分配内存（如空指针）、只读段（如字符串字面量地址）、或未对齐地址（如 i32* 指向地址 0x1001）写入，会在运行时触发 segfault 或硬件异常 —— LLVM 不插手，交给后端和 OS。
典型陷阱：
-
%p = alloca i32后没store就直接load：读到的是栈上随机垃圾值（未定义值，not undefined behavior，但结果不可预测） - 用
alloca分配空间后，用getelementptr偏移到越界位置再store：IR 合法，但运行时踩内存 - 跨函数传递
alloca出来的指针并store：栈帧已销毁，写入野地址
load/store 依赖 alloca / getelementptr 构建合法指针
LLVM IR 中没有“地址常量”概念（除了全局变量名），所有内存访问都基于指针值。最常用路径是：
-
%ptr = alloca i32→ 在当前栈帧分配 4 字节，返回i32* -
store i32 42, i32* %ptr→ 写入 -
%val = load i32, i32* %ptr→ 读出
数组或结构体访问必须用 getelementptr 计算偏移，例如：
%arr = alloca [3 x i32], align 4 %idx0 = getelementptr [3 x i32], [3 x i32]* %arr, i32 0, i32 0 ; → i32* store i32 100, i32* %idx0 %v = load i32, i32* %idx0
注意：getelementptr 不访问内存，只做地址计算；它返回的必须是有效指针类型，否则后续 load/store 会失败。
volatile 和 atomic 语义影响生成代码
普通 load/store 可被优化器重排、合并或消除。加 volatile（如 load volatile i32, i32* %p）会禁止这类优化，强制每次访存 —— 常用于内存映射 I/O，但会显著拖慢性能。
原子操作（如 load atomic i32, i32* %p seq_cst）引入同步语义，对应 CPU 的 ldaxr/stlxr 等指令，用于多线程共享变量。漏掉 atomic 修饰的并发写，会产生数据竞争（data race）。
容易忽略的一点：volatile 不提供原子性，atomic 不隐含 volatile —— 两者解决的问题完全不同，混用或漏用都会导致难以复现的 bug。
