Add FP8 placeholder support to ExecuTorch serialization

[YufengShi-dudu]

Change-Id: Ibb7ef4167ab96426133fce64e34366c365cd12ad

cc @JacobSzwejbka @angelayi

[pytorch-bot]

🔗 Helpful Links

🧪 See artifacts and rendered test results at hud.pytorch.org/pr/pytorch/executorch/19043

• 📄 Preview Python docs built from this PR

Note: Links to docs will display an error until the docs builds have been completed.

❗ 1 Active SEVs

There are 1 currently active SEVs. If your PR is affected, please view them below:

• Run pull request jobs on OSDC runners in shadow mode

✅ No Failures

As of commit 753c9d2 with merge base 5eb8492 ():
💚 Looks good so far! There are no failures yet. 💚

This comment was automatically generated by Dr. CI and updates every 15 minutes.

[YufengShi-dudu]

Hey @digantdesai, could you take a look at this RP? Thank you

[YufengShi-dudu]

@digantdesai @SS-JIA

[digantdesai]

@claude review this PR.

[claude]

Claude finished @digantdesai's task in 3m 52s —— View job

---

Review: Add FP8 placeholder support to ExecuTorch serialization

• Gather context and read changed files
• Review schema changes
• Review serialization/deserialization logic
• Review print_program and tensor changes
• Review test coverage
• Post review feedback

---

Summary

This PR adds FLOAT8E5M2 and FLOAT8E4M3FN dtype support across the ExecuTorch serialization stack. The changes are minimal and consistent with existing patterns:

1. exir/serde/schema.py — Adds FP8 enum values (15, 16) to the serde ScalarType and bumps schema version from (5, 3) → (5, 4).
2. exir/serde/export_serialize.py — Maps torch.float8_e5m2/torch.float8_e4m3fn to the serde ScalarType.
3. exir/tensor.py — Maps FP8 dtypes to the runtime ScalarType enum (values 23, 24 from exir/scalar_type.py).
4. exir/print_program.py — Adds string representations for FP8 types.
5. exir/tests/test_tensor.py — Adds a test for FP8 tensor roundtrip conversion.

Review Feedback

Overall: Looks good. The changes are straightforward and correctly integrate with the two separate ScalarType enums (the serde schema's own numbering and the runtime's c10-compatible numbering). A few minor observations:

1. Serde enum ordering (non-blocking, but worth noting)

In exir/serde/schema.py, FLOAT8E5M2 = 15 and FLOAT8E4M3FN = 16 are placed after UINT16 = 14. The serde schema's numbering is independent from the runtime enum, so the values themselves are fine. However, this schema is append-only for backwards compatibility — once published with schema version (5, 4), these values are locked in. This seems intentional and correctly done.

2. Missing trailing comma (nit)

In exir/serde/export_serialize.py at line 155, the existing torch.uint16: ScalarType.UINT16 entry has no trailing comma. The new FP8 entries also don't add one. This is pre-existing but worth fixing for consistency — adding entries later will cause a larger diff.

Fix this →

3. Test coverage is appropriate

The test creates FP8 tensors via .to(dtype) and verifies the full make_tensor_value → compare_tensors roundtrip. This validates the runtime path (tensor.py). The serde path (export_serialize.py) is not directly tested in this PR, but the mapping is trivial and follows the exact same pattern as every other dtype.

4. Consideration: should FLOAT8E5M2FNUZ / FLOAT8E4M3FNUZ also be added?

The runtime's scalar_type.h also defines Float8_e5m2fnuz (25) and Float8_e4m3fnuz (26), and PyTorch has torch.float8_e5m2fnuz and torch.float8_e4m3fnuz. Depending on whether these are needed for your use case, it might make sense to add them now to avoid a follow-up schema version bump. This is optional and depends on whether those dtypes have active users.

Verdict

LGTM — clean, minimal change that correctly wires up FP8 support through both serialization paths. The schema version bump is appropriate. No correctness issues found.

---

[digantdesai]

Thanks. Any plans to further support this down the lowering pipeline in ET?

[digantdesai]

Thanks. Any plans to further support this down the lowering pipeline in ET?

[digantdesai]

Thanks. Any plans to further support this down the lowering pipeline in ET?

[YufengShi-dudu]

Thanks. Any plans to further support this down the lowering pipeline in ET?

Yes. I'll start working on FP8 operator support for the Arm backend after this patch lands.