llvm不是虚拟机而是编译器基础设施，采用前端→llvm ir→后端三段式解耦架构，支持多语言前端与多目标后端自由组合，ir作为通用中间表示实现一次优化、多端复用。
厂商扩展必须显式写进 -march，不能靠 profile 自动带
LLVM 不会把厂商扩展（如玄铁 xkrypto、xmac 或芯来 xnms）自动注入到 profile 名里。哪怕你用了 -march=rva23u64，它也只包含 RISC-V 官方定义的组合，不会隐含任何厂商扩展。
启用方式只有一种：在 -march 字符串末尾手动追加，例如：
clang --target=riscv64-unknown-elf -march=rv64gc_xkrypto test.c
- 必须指定完整
--target，否则-march可能被降级或忽略 -
xkrypto这类前缀为x*的扩展，需确保编译 LLVM 时启用了-menable-experimental-extensions，否则会被静默丢弃 - profile 名和厂商扩展可以混用，但顺序无关：
-march=rva23u64_xkrypto_zicsr是合法的
clang -print-enabled-extensions 是唯一可信的确认手段
光看编译不报错，不代表扩展真启用了。很多厂商扩展只注册了汇编器支持，IR 层没 intrinsic，后端也不会生成指令。运行以下命令才能看到 LLVM 实际解析出的扩展集合：
clang --target=riscv64-unknown-elf -march=rv64gc_xkrypto -print-enabled-extensions
输出中如果出现 xkrypto，说明前端已识别；若只有 g、c、f，那大概率是没生效。常见失效原因：
- 未加
-menable-experimental-extensions（对绝大多数x*扩展是硬性要求） - LLVM 构建时没启用对应后端支持（比如没打玄铁补丁或没配置
RISCV_ENABLE_VENDOR_EXTENSIONS） -
-march被其他参数覆盖，例如-mcpu没配对，导致 driver 链路中-march被丢弃
验证是否真正生成了厂商指令，得看汇编输出
即使 -print-enabled-extensions 显示了 xkrypto，也不代表代码里调用了它。厂商扩展通常依赖 builtin 或 intrinsic 触发，例如：
__builtin_riscv_xkrypto_aesenc(...)
此时必须检查最终汇编里有没有对应助记符：
clang --target=riscv64-unknown-elf -march=rv64gc_xkrypto -O2 -S -o - test.c | grep aesenc
- 如果没输出，先确认源码中是否真有对应 builtin 调用（拼写、头文件、参数类型都必须匹配）
- 某些厂商指令只在特定优化级别（如
-O2或-O3）下才启用 lowering，-O0很可能 fallback 到软件实现 - 汇编器能识别
xkrypto并不等于后端能生成——llc -mtriple=riscv64 -march=rv64gc_xkrypto --print-isas输出中若无Xkrypto大写项，说明后端子模块未激活
最容易被忽略的点：厂商扩展没有统一 ABI 约定
官方扩展（如 zkn1）有明确的寄存器使用规则和调用约定，但厂商扩展几乎都不定义 ABI。这意味着：
- 不同芯片厂商的
xmac可能用不同 CSR、不同操作码、甚至不同副作用语义 - 同一个
__builtin_riscv_xmac在玄铁和芯来上，生成的指令可能完全不兼容 - 链接多个目标文件时，若一个用了
xkrypto，另一个没启用，ld不会报错，但运行时可能 trap 或行为异常
实际项目中，建议把厂商扩展封装成独立静态库，并强制所有调用点统一编译参数，避免混用。
