Heterogeneous targets · P1-4b: FP8/FP6/FP4 element types + block scaling (Scale<..>)

P1-4b — FP8 / FP6 / FP4 + block scaling (as descriptor-table rows)

ElementType has F16/F32/F64/BF16 and integers down to I4/U4 — no FP8 at all, let alone FP6/FP4 or a microscaled block. NVFP4 (16 values sharing an E4M3 scale) is the entire reason Blackwell exists; this is the marketing surface of every 2026 accelerator and it is unrepresentable. Depends on P1-4a (do them in that order or the work triples).

Proposed — new element types + a scale facet on the tensor type

// element types (table rows, per P1-4a)
//   F8E4M3, F8E5M2      (Hopper/Blackwell FP8)
//   F6E3M2, F6E2M3      (Blackwell FP6)
//   F4E2M1              (Blackwell FP4)
//   F8E8M0              (MX scale type — scales only, never data)

let w : Tensor<f4e2m1, [4096, 4096], Scale<f8e4m3, block: 16>>;   // NVFP4
let m : Tensor<f4e2m1, [4096, 4096], Scale<f8e8m0, block: 32>>;   // MXFP4

These are storage formats, not arithmetic types — and the language should say so

Nobody does elementwise a + b on FP4; NVFP4 is stored 4-bit and computed by the MMA unit accumulating in FP32. So f4e2m1 is legal in a tensor, transferable, capacity-checked, and feedable to a matmul — while scalar arithmetic on it requires an explicit conversion. This split is an accurate model of the hardware, not a compromise.

Byte accounting must include the scale plane

bytes = ceil(numel * data_bits / 8) + ceil(numel / block * scale_bits / 8)

NVFP4 example: 4096*4096*4/8 = 8 MB data + 4096*4096/16*8/8 = 1 MB scales = 9 MB, not 8. Getting this wrong makes E6009 under-report on exactly the workloads people care about.

Diagnostics

E60xx: matmul operands disagree on block scaling
  note: lhs is Scale<f8e4m3, block: 16>, rhs is unscaled f4e2m1
E60xx: 'f4e2m1' is a storage format and has no scalar arithmetic
  help: convert to a computational type (`as f32`), or feed both operands to a matmul

Where it lands

Table rows (P1-4a), Scale facet on Type::Tensor in src/syntax/types.rs, scale-plane arithmetic in static_tensor_bytes, src/parser/types.rs, one melior type handle per format in src/codegen/generator.rs. Excludes NVFP4 microscaling arithmetic (a follow-on).

From the Heterogeneous Target Gap Analysis (§9). Status tracked there and in the P0 decision log. Sibling to the landed P0 work (P0-1 fa056b4e, P0-3 33ce0b64, P0-4 5e10637a, P1-4a-core 34b31902).

Start by reading the P1-4a work, the linked gap analysis and decision log, then inspect src/syntax/types.rs, static_tensor_bytes, src/parser/types.rs, and src/codegen/generator.rs. Done means the listed format rows and Scale tensor facet are represented, scale-plane bytes are included, storage-only arithmetic diagnostics exist, and each format has its codegen handle.