🔵 Low Priority

变更位置：第 2392 行 MaskReg preg_b16 = CreatePredicate<bfloat16_t>(preg_cols_b16);

函数 calcQuantizedFP8Values_DN_B16 是模板，T 可以是 bfloat16_t 或 half。此处硬编码 CreatePredicate<bfloat16_t>，当 T = half 时谓词类型与数据不匹配。

对比 pre-existing 代码第 1006–1007 行 CalcQuantizedFP8Values_B16_Window 使用 CreatePredicate<T>(...) 正确推导为 T。虽然在此硬件上 bf16 和 fp16 共享同一向量寄存器类型且当前未实例化 fp16 用例，但这是潜在的类型 bug，一旦有人添加 fp16 DN 测试即可能触发问题。

修复：将 bfloat16_t 改为 T。

建议：将 CreatePredicate<bfloat16_t> 改为 CreatePredicate<T>，与其他同模式模板函数的写法对齐。

🟡 Medium Priority

变更位置：第 2411 行 vsts((vector_u32 &)vb8_out, (__ubuf__ uint32_t *)dstPtr, dst_byte_offset / 4, PK_B32, preg_b8);

在整个 pre-existing 代码库中，PK_B32 存储模式搭配的是 32-bit 谓词（preg_b32 / preg_ALL）：

此处新代码使用 preg_b8（uint8_t 粒度谓词，validCols * 2 个元素），与 PK_B32 的 32-bit 通道语义不匹配，可能导致存储掩码错误，在尾迭代时产生数据错写或漏写。

注意：preg_b8 仍在第 2409 行的 vor 操作中使用（该用法正确，与第 978/1044 行一致），因此只需修改第 2411 行的 vsts 谓词为 preg_b32（已定义于第 2394 行）。

建议：将第 2411 行的 preg_b8 改为 preg_b32（该变量已在第 2394 行创建），与 PK_B32 存储模式的 32-bit 谓词语义保持一致。

🟡 Medium Priority

变更位置：第 2442 行 vsts((vector_u8 &)vb8_out, dstPtr, r * StaticCols + vl_start, PK4_B32, preg_b8);

与 Finding #1 和 #2 一致的谓词类型错误：PK4_B32 在整个 pre-existing 代码库中搭配的是 32-bit 谓词（preg_b32），此处使用 preg_b8（uint8_t 粒度，validCols * 4 个元素）与 PK4_B32 的 32-bit 通道语义不匹配。修复：将 preg_b8 改为 preg_b32（已定义于第 2432 行），并移除第 2431/2433 行仅为此 store 创建的 preg_cols_b8 和 preg_b8。

建议：将第 2442 行的 preg_b8 改为 preg_b32，移除不再需要的 preg_cols_b8（第 2431 行）和 preg_b8（第 2433 行）。

🔵 Low Priority

变更位置：第 2498 行 __ubuf__ uint8_t *expDnPtr = (__ubuf__ uint8_t *)__cce_get_tile_ptr(expDn);

expDnPtr 声明并初始化后在该函数体中从未被使用。与此同时 TQuant_MXFP8_Impl_DN 声明 expDn 参数带有 __out__ 标注，承诺向该 tile 写入输出，但实际未写入任何内容。

虽然调用方（tquant_dn_kernel.cpp 第 158 行）通过 TMOV(e8DnTile, e8Tile) 自行拷贝，但此 dead code 会造成：

1. 不必要的 __cce_get_tile_ptr 调用开销
2. 中间 TRESHAPE_IMPL(*expDn, flatExpDn)（TQUANT_IMPL 第 2651 行）将 flatExpDn 的未写入内容（零值）回写至 expDn，然后立即被 TMOV 覆盖 — 浪费且令人困惑

修复：删除该行，或如果 DN exp 输出未来需要独立计算逻辑，添加 TODO 注释说明。

建议：移除未使用的 expDnPtr 声明，或添加注释说明为何声明但未使用。同时考虑在函数注释中说明 expDn 参数在此阶段仅由调用方通过 TMOV 填充。

🟡 Medium Priority

变更位置：gen_data.py 第 38–49 行，fp32_maxes_to_fp8 函数。

Python golden 数据生成器将所有 exponent == 255 的值都标记为 NaN（第 46 行 nan_mask = exponent_b32 == 255），并在 e8m0 写入 0xFF、scaling 写入 NaN。

但内核 ExtractB8ExponentAndScalingVL<float>（第 773–776 行）通过两步区分 NaN 和 Inf：

1. vcmps_eq(preg_special, exponent, 0xFF) → 标记所有 exponent==255 为"特殊值"
2. vcmps_ne(preg_nan, mantissa, 0, preg_special) → 仅 mantissa != 0 的才是 NaN

Inf（exponent=255, mantissa=0）在 kernel 中走正常路径（shared_exp=247, scaling=2^-120），但 Python 中却被写入 NaN scaling 和 0xFF exponent。这使得 golden reference 在涉及 Inf 输入时与内核输出不一致。

当前随机测试数据未产生 Inf/NaN，故不影响当前测试结果。但当生产数据中出现 Inf 时，golden 对比将错误报告 mismatch。

修复方向：将 Python 中的 nan_mask = exponent_b32 == 255 改为 nan_mask = (exponent_b32 == 255) & (mantissa_bits != 0)，与内核语义匹配。

建议：将 nan_mask 改为同时检查 mantissa != 0：(max_bits & 0x007FFFFF) != 0，与内核的 NaN 判断逻辑（exponent==255 AND mantissa!=0）对齐。