-zkn 不生效是因为 llvm 不支持模糊前缀匹配，必须显式写全如 zkn1；启用实验性扩展需同时加 -menable-experimental-extensions 和完整 -march 名称，且工具链各组件须协同支持。
为什么 -march 里写 +zkn 不生效
LLVM 不会自动推导实验性扩展的子版本。比如 zkn1 和 zkn2 是两个独立注册的扩展，+zkn 这种模糊前缀根本不会被解析——RISCVISAInfo.cpp 里没有对应规则，parseArchExt 函数直接跳过。你看到的 zkn* 列表，全是硬编码在源码里的完整字符串（如 "zkn1"、"zkr"），不是靠通配匹配出来的。
常见错误现象：
- 编译命令写了
-march=rv64gc+zkn，但-print-enabled-extensions输出里完全不见zkn1 - 调用
__riscv_aes32esmi时提示use of unknown builtin，即使头文件已包含
必须显式写全名，例如：
clang --target=riscv64-unknown-elf -march=rv64gc_zkn1 -print-enabled-extensions
否则 LLVM 就当它不存在。
-menable-experimental-extensions 是开关，不是补丁
这个 flag 的作用非常具体：它只是告诉 RISCVSubtarget.cpp 去加载那些 let Unsupported = 1 或 let Experimental = 1 的扩展声明。不加它，哪怕源码里已有 def Zkn1，parseArchExt 也会直接过滤掉该字符串。
使用场景：
- 启用尚未进入正式规范的厂商扩展（如平头哥的
xkrypto） - 测试 LLVM 主干中刚合入、但还没打上 stable 标签的
zvkng、zvkt等向量密码扩展 - 验证自定义扩展是否被正确注册（先加 flag，再看
--target-help是否出现）
注意：-menable-experimental-extensions 必须和 -march 同时出现，单独加没用；它也不影响已稳定扩展（如 zba、zbb）的行为。
实验性扩展的“支持”不等于“可用”
即使 -print-enabled-extensions 显示了 zvksg，也只代表前端能解析、IR 层能建模，不代表后端能生成指令或 intrinsic 可调用。
容易踩的坑：
-
riscv_crypto.h里没声明对应 intrinsic → 检查 clang 安装路径下的头文件是否来自同一版本构建（不同 LLVM 版本的include/riscv_crypto.h差异极大） - llc 生成非法指令 → 查
llvm/lib/Target/RISCV/RISCVInstrInfo.td里是否有def AES32ESMI类定义，以及是否绑定了正确的SchedRW和DecoderMethod - 汇编器报
unknown architectural extension 'zvksg'→ binutils 版本太旧，不识别该扩展编码，需同步升级gas和objdump
真正卡住的地方往往不在 clang，而在整个工具链对新扩展的协同支持程度——LLVM 能 parse，不等于 binutils 能 encode，更不等于 QEMU 或 FPGA 固件能 decode 执行。
