llvm编译risc-v内联汇编需严格匹配abi、显式声明clobber（含"memory"）、强制volatile、指令间用\n\t分隔、rvv须手动vsetvli；约束符不能照搬x86，寄存器名需显式指定。
LLVM 编译 RISC-V 程序时，asm 内联汇编的行为和 GCC 基本一致，但有几个关键点必须手动对齐，否则会编译失败、寄存器冲突或生成非法指令。
内联汇编语法本身不依赖 LLVM，但约束符和破坏列表必须匹配 RISC-V ABI
RISC-V 的调用约定（如 a0–a7 传参、s0–s11 被调用者保存）直接影响内联汇编的约束写法。你不能照搬 x86 的 "r" 或 "=r" 就完事——LLVM 后端在 codegen 阶段会检查寄存器类是否合法，若约束要求一个被调用者保存寄存器（比如 s0），而你又没在 clobber 里声明，LLVM 可能静默插入保存/恢复代码，也可能直接报错 error: invalid operand for constraint 'r'。
- 输入/输出用
"r"是安全的：它让 GCC/Clang 自动分配任意通用寄存器（x1–x31，不含 x0） - 想固定用某个寄存器（如强制用
a0），得用寄存器名约束："=r"(res), "0"(a)表示输出和第一个输入共享同一寄存器；或显式写"=r"(res), "{a0}"(a) - clobber 列表必须包含所有被修改但未声明为输出的寄存器，例如用了
t0和t1，就得写"t0", "t1"；如果改了内存（比如执行了sw），必须加"memory"
volatile 不是可选的，而是防止优化导致寄存器重用的关键开关
不加 volatile 时，Clang 可能将多条 asm 合并、重排，甚至删掉看似“无副作用”的指令（比如只读内存的 lw）。更危险的是：若两条内联汇编之间没有数据依赖，编译器可能把前一条的输出寄存器复用于后一条的输入，造成值被意外覆盖。
- 所有含硬件交互、内存访问、状态变更（如
csrrw修改 CSR）、或依赖精确执行顺序的内联汇编，必须加volatile - 仅做纯计算且无副作用的片段（极少见），才可考虑省略，但风险自担
- 不要用
__volatile__替代——Clang 对双下划线形式支持不稳定，统一用volatile
字符串里的换行和分号必须显式写出，否则 Clang 会解析失败
LLVM 的 AsmParser 对指令格式比 GCC 更严格。如果你写：
asm volatile("add %0, %1, %2" : "=r"(res) : "r"(a), "r"(b));
这在大多数情况下能过，但一旦涉及多条指令、立即数约束或 CSR 操作（如 csrrsi），就容易触发 error: unknown token in expression。根本原因是 Clang 默认把整个字符串当单条指令处理，没做分行解析。
- 每条指令末尾必须有
\n\t或;，推荐统一用\n\t（GNU as 标准） - 正确写法：
"add %0, %1, %2\n\tsub %0, %0, %3\n\t" - 用
;分隔也行，但注意某些伪指令（如.option push）不支持分号结尾，此时必须用换行 - 避免用反斜杠续行（
\）包裹长指令——Clang 的 lexer 有时会吞掉换行符，导致语法错误
RVV（向量扩展）内联汇编必须配合 vsetvli 手动设 VL，且不能依赖编译器推导
LLVM 不会对内联汇编里的 RVV 指令（如 vadd.vv）做任何向量化分析或 VL 推导。你写的每一条向量指令都按字面意思翻译，如果当前 VL 为 0 或不匹配数据长度，运行时就会 trap。
- 必须在向量指令前显式插入
vsetvli，例如："vsetvli t0, %2, e32, m1\n\tvadd.vv %0, %1, %3\n\t" - 立即数参数（如
e32,m1）不能用 C 变量替代——它们是汇编时确定的常量，需硬编码 - 别指望
__riscv_vsetvl_e32m1()这类 intrinsic 和内联汇编混用能自动同步 VL；它们属于不同抽象层，寄存器状态不互通 - 若需动态 VL，把
vsetvli的结果（t0）作为输出约束，再传给后续指令使用
最易被忽略的是 clobber 中的 "memory" ——哪怕你只读不写，只要访问了内存地址（比如 lw a0, 0(a1)），就必须声明，否则 LLVM 可能在其前后重排内存操作，破坏语义。
