add vcvt f162bf16 and s82f16

[Likai-19]

概述

本 PR 在 VPTO 和 VMI 两层新增三条 vcvt 转换路径：

• VPTO pto.vcvt f16→bf16
  在 lookupVcvtContract 中新增 F16→BF16 合约：requiresRnd=true、requiresSat=false、requiresPart=false。
  生成 intrinsic：llvm.hivm.vcvtff.f162bf16.x。
  与已有的 bf16→f16 不同，f16→bf16 不需要 SAT：f16 的指数范围是 bf16 的子集，不会溢出。

• VMI pto.vmi.vcvt f16→bf16
  在 lookupVMIFpToFpContract 中新增同语义的 f16→bf16 合约。
  现有同宽度 lowering 路径 OneToNVMITruncFOpPattern 可直接处理，不需要额外 lowering 改动。

• VMI pto.vmi.vcvt s8→f16
  扩展 VMISIToFPOp::verify()，允许 si8→f16。
  扩展 OneToNVMISIToFPOpPattern 和 checkSupportedSIToFPShape，将 8→16 整型转浮点直接 lowering 为 pto.vcvt {part=EVEN/ODD}。
  最终目标 intrinsic 为 llvm.hivm.vcvtif.s82f16.x。

代码改动

VPTO 层

• lib/PTO/IR/VPTO.cpp
  在 lookupVcvtContract 中新增 F16→BF16 分支：requiresRnd=true, requiresSat=false, requiresPart=false。
  lib/PTO/Transforms/VPTOLLVMEmitter.cpp
  为非 CANN900 / A2-A3（dav-c220）VPTO LLVM 路径新增 llvm.hivm.vcvtff.f162bf16.x intrinsic 映射。
• lib/PTO/Transforms/VPTOCANN900LLVMEmitterTypeHelpers.cpp
  在 kVcvtContractEntries 中为 CANN900 路径新增一行 F16→BF16 表项。
  本 PR 不修改 VPTOCANN900LLVMEmitter.cpp；它仍保持为 stub，由拆分后的 CANN900 emitter 实现分发。
  VMI 层
• lib/PTO/IR/VMI.cpp
  lookupVMIFpToFpContract：新增 f16→bf16 合约（requiresRnd=true、requiresSat=false）。
  VMISIToFPOp::verify()：在原有 si32→f32 基础上允许 si8→f16。
• lib/PTO/Transforms/VMIToVPTO.cpp
  OneToNVMISIToFPOpPattern：同时支持同宽度 si32→f32（1:1，rnd=R）和扩宽 si8→f16（EVEN/ODD 分片，无 rnd/sat）。
  checkSupportedSIToFPShape：通过 cast-layout 框架支持 si8→f16。
  OneToNVMITruncFOpPattern：更新注释，补充 f16→bf16。

[mouliangyu]

检视结论：两条新增转换的功能链路正确，但需先修复合规阻塞项。\n\n本地在当前 main 合并树上完成 LLVM 19 全量构建，3 条相关 lit 通过；vcvt f16 -> bf16 与 s8 -> f16 两个 runtime case 均在 simulator 上 compare passed。VMI/VPTO contract 及 LLVM intrinsic 映射未发现语义问题。\n\n需要修改：\n\n1. lib/PTO/IR/VMI.cpp:827、2313 及 lib/PTO/Transforms/VMIToVPTO.cpp 中本 PR 新增的多处 if/loop 控制体未使用花括号，违反必选规则 G.FMT.11-CPP。\n2. 两个新增 runtime main.cpp 也存在无花括号控制体，并使用 atoi 解析外部输入，无法报告非法输入和越界（G.FUU.22）。\n3. 两个 compare.py:21 均为 148 列，超过项目 120 列限制（G.FMT.02）。\n\n复跑 changed-code checker 结果为 22 errors / 4 warnings。请修复全部同类项后再更新。

[Zhendong404]

Blocker：这个文件的改动是一次隐性的大面积回退，请重做。

main 在 2026-08-27 刚合入 "refactor: split CANN900 emitter implementation"，把原来的单体 emitter 拆成了 stub + VPTOCANN900LLVMEmitterInternal.h + 8 个拆分 .cpp（ArithmeticPatterns / CalleeCore / TypeHelpers 等）。本 PR 把这个 stub 直接覆盖回 ~12000 行的单体文件（占整个 PR 增量的 90%+），而拆分出的 8 个文件仍留在树里、变成死代码。

可以确认这份单体内容是拆分之前的旧快照，而不是基于新代码的同步：

• 这里的 lookupVcvtContract 还是 switch 结构；main 拆分后已改为 kVcvtContractEntries[] 表驱动（VPTOCANN900LLVMEmitterTypeHelpers.cpp），且 VcvtContract 多了显式 satBeforeRnd 字段。
• main 的合约表里已经有 S8→F16（vcvtif.s82f16，TypeHelpers.cpp:1297）——CANN900 路径的 s8→f16 在 main 上已存在，这里是在旧代码上重复实现了一遍。
• 拆分之后对那 8 个文件做的任何修复，都会被这份旧快照在 CANN900 路径上静默丢掉。由于单体内容放在匿名命名空间里，编译链接不会报重复符号，CI 可能是绿的，问题更难被发现。

CANN900 侧本次真正需要做的，只是往 VPTOCANN900LLVMEmitterTypeHelpers.cpp 的合约表里加一行 F16→BF16 表项。请基于最新 main 重新做这个改动。

[Likai-19]

已修改

[Zhendong404]

PR 描述里说改了 lib/PTO/Transforms/VMILowerUnifiedToLegacy.cpp 的 lowerVCvt（不再把 s8→f16 分解为 extsi→sitofp→truncf，而是直接创建 VMISIToFPOp），但这次 diff 里并没有包含这个文件。

需要确认一下：

• 如果这条改动在 rebase 中丢了，那么"不再走三步分解"的前提是否还在 main 上成立？当前的 lowerVCvt 对 s8→f16 实际走的是什么路径？
• 如果 main 上已经是直接创建 VMISIToFPOp（无需再改），请更新 PR 描述，避免误导 reviewer。

[Likai-19]

该描述已过时，lowerVCvt 对 s8→f16 实际走的已经是直接lowering成对应vpto的形式。已更新pr描述。

[Zhendong404]

ST用例能否直接使用PTODSL测试框架，就不用加这么多文件了，参考：test/vpto/cases/micro-op/a5-extra/vmadd.py