targetdatalayout 字符串必须在 targetmachine 构造时显式传入，决定abi关键参数（如指针大小、对齐、整数位宽），不可依赖triple自动推导或.td文件定义；ir中硬编码的targetdatalayout优先级最高，影响指令选择、栈布局与内存访问正确性。
targetdatalayout 字符串必须在 TargetMachine 初始化时提供
LLVM 后端不通过 .td 文件或 TableGen 定义数据布局；它由 TargetMachine 构造时传入的 StringRef DataLayoutString 决定。这个字符串最终被封装进 DataLayout 实例，用于指导 ABI 相关决策（如结构体字段对齐、指针大小、整数位宽等）。
常见错误是试图在 MyArch.td 里写 layout 规则，或在 MyArchTargetMachine.cpp 中漏传该字符串——这会导致后端生成错误的内存布局，比如 struct 成员错位、sizeof(void*) 不匹配目标 ABI。
- 必须在
MyArchTargetMachine的构造函数中显式传入，例如：MyArchTargetMachine(const Target &T, const Triple &TT, StringRef CPU, StringRef FS, const TargetOptions &Options, Reloc::Model RM, CodeModel::Model CM, CodeGenOpt::Level OL)→ 调用父类构造时填入"e-m:e-p:32:32-i64:64-n32-S128"这类字符串 - 字符串格式严格遵循 LLVM DataLayout 语法，不能省略关键字段：字节序（
e或E）、指针大小（p:32:32表示 32 位指针，地址空间 0 的指针大小和 ABI 对齐均为 32）、整数位宽（i64:64）、向量对齐（S128）等 - 若目标架构有多个 ABI 变种（如 RISC-V 的 ilp32 vs lp64），需为每个变种注册独立的
TargetMachine子类，并各自传入对应targetdatalayout
target-triple 决定默认 data layout，但不可依赖自动推导
Triple（如 "riscv32-unknown-elf"）本身不携带 layout 信息；LLVM 仅在未显式指定 DataLayoutString 时，用内置 fallback（如 "e-m:e-p:32:32-i64:64-n32-S128"）凑一个，但这通常不满足真实硬件要求。
例如：某 32 位嵌入式架构要求 long 为 64 位且按 8 字节对齐，但默认 fallback 给的是 i64:64 且没声明 long 的 ABI 映射 —— 必须手动在字符串中加入 L64（表示 long 为 64 位）和 A8（ABI 对齐为 8）。
- 实际项目中应从目标 ABI 文档（如 AAPCS、RV32I ABI）直接提取 layout 参数，而非靠猜
- Clang 命令行传入的
--target=xxx最终也只影响Triple，不自动注入 layout；layout 仍由后端TargetMachine实现决定 - 可通过
llc -mtriple=myarch-unknown-elf -mcpu=xxx test.ll -o -配合-debug-only=dag-isel观察 IR 解析阶段是否报Invalid data layout
IR 模块中的 targetdatalayout 属性优先级最高
当使用 llc 编译一个已含 targetdatalayout 的 .ll 文件时，该字符串会覆盖后端 TargetMachine 提供的默认值。这是调试 layout 问题的关键切入点。
典型误操作：修改了 MyArchTargetMachine 的 layout 字符串，但测试用的 test.ll 文件头部自带 targetdatalayout="e-m:e-p:64:64-..."，导致后端完全不生效。
- 检查 IR 文件是否硬编码 layout：用
grep "targetdatalayout" test.ll - 临时绕过 IR 中的 layout：加
-mattr=+override-layout（需后端支持）或直接删掉 IR 文件首行的targetdatalayout声明 - 验证 layout 是否生效：在
SelectionDAGBuilder或LowerFormalArguments中打日志，调用DAG.getDataLayout().getPointerSize(0)看返回值
data layout 影响指令选择和栈帧布局，不是可选配置
看似只是“描述性字符串”，但它直接影响 TargetLowering 中的合法化逻辑（isTypeLegal）、FrameLowering 的栈偏移计算、甚至 SelectionDAG 节点的类型展开方式。忽略它，寄存器分配可能把 64 位值拆成两个 32 位寄存器存，而硬件根本不支持该拆分方式。
最容易被忽略的一点：struct 字段对齐不一致会导致 getelementptr 计算出错偏移，进而让 Load/Store 指令访问越界地址 —— 这类 bug 在模拟器里可能静默运行，但在真机上直接触发总线错误。
- 务必用真实 C 头文件生成 IR 测试 layout：
echo 'struct { int a; long b; }' | clang -x c -target=myarch-unknown-elf -emit-llvm -S -o -，检查生成的%struct.anon = type { i32, i64 }是否被正确填充（padding 字段是否出现） - 若目标架构要求非标准对齐（如所有指针强制 16 字节对齐），必须在 layout 字符串中明确写
p:32:16，否则getPointerAlignment返回 4，后续优化会出错 - data layout 改变后，必须重新生成所有 TableGen 文件（
tblgen），因为某些*GenRegisterInfo.inc中的常量可能隐式依赖指针大小
