feat(intrinsics): admit bf16x2 to FP8x2 pack conversions

[YeonwooSung]

What this adds

Four Blackwell-family pack conversions from packed bf16x2 to packed FP8, admitted to the intrinsic catalog as inline-PTX records: cvt_rn_satfinite_e4m3x2_bf16x2, cvt_rn_satfinite_relu_e4m3x2_bf16x2, cvt_rn_satfinite_e5m2x2_bf16x2 and cvt_rn_satfinite_relu_e5m2x2_bf16x2. The generator emits the cuda_device::convert stubs, dialect-nvvm ops, importer arms, mir-lower lowerings, ABI ledger entries i1030 to i1033 and the reference rows, the same way as the f16x2 siblings. cuda-target-spec gains the +ptx91 feature these instructions need.

before: a kernel holding bf16 pairs unpacks to two f32 and packs those
  cvt.f32.bf16 + cvt.f32.bf16 + cvt.rn.satfinite.e4m3x2.f32     3 instructions, 2 extra registers per pair
after:
  cvt.rn.satfinite.e4m3x2.bf16x2 %rs1, %r1;                       1 instruction, PTX 9.1, Blackwell families

use cuda_device::convert::{cvt_rn_satfinite_e4m3x2_bf16x2, cvt_rn_satfinite_relu_e5m2x2_bf16x2};

// packed bf16x2 bits in, packed FP8x2 bits out; the low bf16 half lands in the low byte
let e4m3: u16 = cvt_rn_satfinite_e4m3x2_bf16x2(packed_bf16x2);
let e5m2_relu: u16 = cvt_rn_satfinite_relu_e5m2x2_bf16x2(packed_bf16x2);

Build with cargo oxide run <example> --arch sm_120a (or sm_120f). CUDA 13.4's own cuda_fp8.hpp emits the same instruction for __nv_cvt_bfloat16raw2_to_fp8x2 under family-specific compilation.

What we fixed

• Recorded the LLVM evidence under the current rust-llvm-23.1.3-aab11ee0 profile with the typed-NVVM stages and the ptxas assembly the packed-conversion family requires, and removed the bf16x2 exemption from the evidence validator. The pinned llc selects llvm.nvvm.bf16x2.to.* at sm_100f and sm_120a with +ptx91.
• Replaced the libNVVM evidence with a real libNVVM 13.3.73 compile, ptxas assembly and nvJitLink link; the submitted file reused the f16x2 sibling's header around an llc run.
• Widened the target set from sm_100f|sm_110f|sm_120f to the family list the catalog uses for Blackwell records. The compiler matches family targets on the literal f suffix, so the short list refused --arch sm_120a and sent an arch-less cargo oxide run on an RTX 5090 to sm_100f, which failed at module load.
• Added the PTX 9.1 needs LLVM 23 rule to the PTX ISA gate. LLVM 22 knows +ptx90 only; with CUDA_OXIDE_LLC=llc-22 the build was silent, the PTX said .version 8.8, and the JIT failed at load. The examples-compile lane's LLVM floor moves from 22 to 23 for the same reason.
• Merged main and regenerated, refreshed the book catalog stamp and counts, added the negative admission cases the f16x2 test has, and extended generated_intrinsics_blackwell with the four bf16x2 forms.

Target contract

• PTX 9.1 floor. Accepted targets: sm_100a, sm_100f, sm_103a, sm_103f, sm_110a, sm_110f, sm_120a, sm_120f, sm_121a, sm_121f. The PTX ISA admits family features on f-targets and on a-targets of the same family; ptxas 13.4 and the pinned llc accept the same set.
• Refused at compile time: unsuffixed sm_100, sm_103, sm_110, sm_120 and sm_121, sm_90a and older, and any llc older than LLVM 23.
• cargo oxide run with no --arch selects the detected device (sm_120a on a 5090); cargo oxide build with no --arch compiles for the first catalog alternative, as for every family-gated record, so pass --arch for a specific device.

Implementation

• intrinsics/overlay/packed_conversion_fp8_bf16x2.toml (schema 65) is a compact shard: fp8_formats = ["e4m3x2", "e5m2x2"], relu_variants = true, product_count = 4, runtime_validation = "unexecuted"; listed in overlay.toml.
• PackedConversionFp8Bf16x2Admission fails closed on any axis deviation and builds records through the shared packed_conversion_overlay_record; four closed recipes carry the ids, ABI ids, operation keys, the v2bf16 -> i16 typed signature and the mnemonics.
• PackedConversionSourceFormat::Bf16x2 extends every render and resolve match beside F16x2: 32-bit u32 source, u16 result, =h,r constraint, identity half order; the generated mir-lower impl is a convert_generated_packed_unary call like its siblings.
• packed_conversion_floor returns the 9.1 floor with no minimum SM and the family target list through a named const with the derivation in its comment.
• cuda-target-spec adds 91 to the PTX feature vocabulary; the gate in cuda-oxide-codegen is a table of PTX floor to LLVM major (9.0 needs 22, 9.1 needs 23).
• Evidence: rust-llvm-23.1.3-aab11ee0-packed-conversion-fp8-bf16x2.json and cuda-13.3-libnvvm-13.3.73-packed-conversion-fp8-bf16x2.json, recorded from real tool runs.

Verification

Checked at 89e24e263 (nightly-2026-10-11, RTX 5090):

• ✅ cuda-intrinsics-gen check current, probe --all --skip-terminal --per-target green, check-abi-history with the 1029 base entries preserved and 1033 total; a second generate is a no-op; the book catalog stamp guard passes.
• ✅ cargo test -p cuda-intrinsics-gen --all-targets, cargo test -p cuda-oxide-codegen (the gate test fails without the 9.1 rule), the touched crates' clippy with warnings as errors, rustdoc, fmt, the 18 guards and the lock check.
• ✅ cargo oxide run generated_intrinsics_blackwell --arch sm_120a: all 16 bf16x2 checks match (0x4038/0x403c, 0x7eb8/0x7e00, +Inf and NaN cases), memcheck 0 errors; the PTX is .version 9.1 with one cvt.rn.satfinite[.relu].{e4m3x2,e5m2x2}.bf16x2 per form.
• ✅ Arch-less cargo oxide run on the 5090 selects sm_120a and passes; CUDA_OXIDE_LLC=llc-22 is refused at compile time with the LLVM 23 message.
• ✅ Review runs at the submitted head: all four forms over every bf16 pattern in each lane, 0 mismatches against CUDA 13.4's cuda_fp8.h host conversion, through the llc and libNVVM routes; ptxas 13.4 accepts the instruction on the ten family targets and rejects unsuffixed sm_100 and sm_120.

Caveats

• runtime_validation stays unexecuted in the catalog: compact admissions have no runtime stage to record (intrinsics-gen: runtime_validation = "executed" is unreachable for compact admissions (30 guards, no Runtime-stage producer) #1298), so the GPU results live in this description and in the Blackwell example.
• Pack only. The pinned LLVM import has no unscaled unpack record (cvt.rn.bf16x2.e4m3x2 is PTX 9.2).
• Family-gated: there is no sm_89 or sm_90 form of this instruction; the f32-pair conversions remain the portable route.
• probe --candidate cannot record evidence for this family (a pre-existing panic in the packed renderer); the evidence was recorded with the same process as the f16x2 refresh.

[copy-pr-bot]

This pull request requires additional validation before any workflows can run on NVIDIA's runners.

Pull request vetters can view their responsibilities here.

Contributors can view more details about this message here.

[nihalpasham]

/ok to test 89e24e2

[nihalpasham]

Thanks, the four records are right and the generated code is correct: on the 5090 all four forms are bit for bit equal to CUDA's own cuda_fp8.h conversion. The gaps were in the evidence and the gates, so I layered those on top:

• Re-recorded the LLVM evidence under the current toolchain profile with the typed stages the family requires, and replaced the libNVVM file with a real libNVVM, ptxas and nvJitLink run.
• Widened the targets to the full Blackwell family list; the f-only list refused --arch sm_120a and sent an arch-less run on a 5090 to sm_100f.
• Added the rule that PTX 9.1 needs LLVM 23: llc-22 silently emitted .version 8.8 PTX that failed at load. The examples CI lane moves to LLVM 23 for the same reason.
• Merged main, regenerated, added the negative admission tests and the four forms to generated_intrinsics_blackwell.

At 89e24e263, the catalog gates, the crate tests, the guards, the Blackwell example on sm_120a with memcheck clean, and all CI checks passed.