Support `SaturatedToLargestFloat8NormalConversionEXT` decoration by vmaksimo · Pull Request #3767 · KhronosGroup/SPIRV-LLVM-Translator

vmaksimo · 2026-06-01T10:49:52Z

Add round-trip handling for SPV_EXT_float8's saturating FP-to-FP8 conversion.

At the LLVM IR level it is represented via _sat suffix on the existing __builtin_spirv_Convert<Src>To<E4M3|E5M2>EXT interface. When _sat is present, the resulting OpFConvert is decorated with SaturatedToLargestFloat8NormalConversionEXT.

AI-assisted: Claude Opus 4.7 (commercial SaaS)

Add round-trip handling for `SPV_EXT_float8`'s saturating FP-to-FP8 conversion. At the LLVM IR level it is represented via `_sat` suffix on the existing `__builtin_spirv_Convert<Src>To<E4M3|E5M2>EXT` interface. When `_sat` is present, the resulting OpFConvert is decorated with `SaturatedToLargestFloat8NormalConversionEXT`. AI-assisted: Claude Opus 4.7 (commercial SaaS)

MrSidims · 2026-06-01T11:52:35Z

At the LLVM IR level it is represented via _sat suffix on the existing __builtin_spirv_ConvertTo<E4M3|E5M2>EXT

Shouldn't it be __builtin_spirv_ClampConvert<Src>To<E4M3|E5M2> instead?

vmaksimo · 2026-06-01T13:18:46Z

At the LLVM IR level it is represented via _sat suffix on the existing __builtin_spirv_ConvertTo<E4M3|E5M2>EXT

Shouldn't it be __builtin_spirv_ClampConvert<Src>To<E4M3|E5M2> instead?

I believe it can be both, wanted to publish this for discussion to choose the preferrable one.

MrSidims · 2026-06-01T13:23:30Z

I'd not create instances without necessity :)

Address review feedback on the previous commit: instead of introducing a `_sat` suffix on `__builtin_spirv_Convert<Src>To<E4M3|E5M2>EXT`, reuse the existing `__builtin_spirv_ClampConvert<Src>To<E4M3|E5M2>INTEL` interface from `SPV_INTEL_fp_conversions`. When `SPV_EXT_float8` is enabled, those four FP8-result entries are now emitted as `OpFConvert` decorated with `SaturatedToLargestFloat8NormalConversionEXT` instead of `OpClampConvertFToFINTEL`, and round-trip back to the same builtin names. The reverse translator also rejects modules where this decoration targets a non-FP8 conversion: per spec it may only decorate `OpFConvert`/`OpConvertSToF`/`OpConvertUToF` with an `Float8E4M3EXT` or `Float8E5M2EXT` Result Type, and `spirv-val` does not enforce this yet. AI-assisted: Claude Opus 4.7 (commercial SaaS)

vmaksimo · 2026-06-02T12:44:25Z

CI failures are caused by llc change llvm/llvm-project#200791

MrSidims

Fine with me, but if I were you - I'd get someone from Intel to approve :)

YuriPlyakhin · 2026-06-09T01:08:07Z

+      bool IsSaturatedFP8 =
+          FPDesc.ConvOpCode == internal::OpClampConvertFToFINTEL &&
+          (FPDesc.DstEncoding == FPEncodingWrap::E4M3 ||
+           FPDesc.DstEncoding == FPEncodingWrap::E5M2) &&
+          BM->isAllowedToUseExtension(ExtensionID::SPV_EXT_float8);


When SPV_INTEL_fp_conversions is enabled, the writer used to emit OpClampConvertFToFINTEL for __builtin_spirv_ClampConvert<...>To<E4M3|E5M2>INTEL. With this PR the writer always rewrites to OpFConvert + SaturatedToLargestFloat8NormalConversionEXT. There's no longer a way to ask the translator to emit OpClampConvertFToFINTEL with an FP8 result type.

Is that intended?

If SPV_EXT_float8 is meant to supersede SPV_INTEL_fp_conversions for FP8 destinations, please call that out in PR description.

Nice catch, I was a bit rush to change the behavior. Restored the behavior for SPV_INTEL_fp_conversions in a577c55 so SPV_EXT_float8 does not supersede

With this PR the writer always rewrites to OpFConvert + SaturatedToLargestFloat8NormalConversionEXT. There's no longer a way to ask the translator to emit OpClampConvertFToFINTEL with an FP8 result type.

Is it bad?

I don't know, maybe it is good. I was just asking, if it was the intention. :)
@vmaksimo , you might want to verify with @gmlueck and @bashbaug on how we want these 2 extensions to coexist...

My intent is to simplify this very change to have the decoration support from the multi-vendor extension.
I'd prefer to resolve any collisions with the INTEL extension in a separate PR when we clarify our spec changes

If SPV_EXT_float8 is meant to supersede SPV_INTEL_fp_conversions for FP8 destinations, please call that out in PR description.

I think we do want SPV_EXT_float8 to supersede SPV_INTEL_fp_conversions. Before @bashbaug went on vacation, he updated the draft SPV_INTEL_fp_conversions to remove the overlapping parts like OpClampConvertFToFINTEL. Therefore, we shouldn't be emitting those instructions.

It would be nice to get this change into the SPRIV Translator before merging intel/llvm#21568, so that we don't have compiled SYCL applications using the outdated OpClampConvertFToFINTEL, etc. instructions.

I talked to @YuriPlyakhin offline. If you want to make the change that causes SPV_EXT_float8 to supersede SPV_INTEL_fp_conversions in a separate PR, that's OK with me. I only wanted to say that we should have this as a goal. I don't mind if it happens in a separate PR.

- Preserve SPV_INTEL_fp_conversions encoding when both extensions are enabled: keep emitting OpClampConvertFToFINTEL for the ClampConvert<Src>To<E4M3|E5M2>INTEL builtins. The OpFConvert + SaturatedToLargestFloat8NormalConversionEXT encoding is emitted only when SPV_EXT_float8 is enabled and SPV_INTEL_fp_conversions is not. - Reader: scope the ClampConvertFToFINTEL rmap rewrite to OpFConvert. The decoration is also valid on OpConvertSToF/OpConvertUToF, but there is no {Integer, E4M3/E5M2, OpClampConvertFToFINTEL} entry in the FP-conversions encoding map; restricting the rewrite avoids an rmap assert on integer-source conversions. - Drop a comment that duplicated the error message text. AI-assisted: Claude Opus 4.7 (commercial SaaS)

YuriPlyakhin · 2026-06-10T00:30:40Z

@@ -0,0 +1,56 @@
+; Clamping FP-to-FP8 conversions: when SPV_EXT_float8 is enabled, the


nit

Suggested change

; Clamping FP-to-FP8 conversions: when SPV_EXT_float8 is enabled, the

; Clamping FP-to-FP8 conversions: when SPV_EXT_float8 is enabled and SPV_INTEL_fp_conversions is not, the

YuriPlyakhin

LGTM. one nit.

…` decoration (KhronosGroup#3767) Add round-trip handling for `SPV_EXT_float8`'s saturating FP-to-FP8 conversion. At the LLVM IR level it is represented via `_sat` suffix on the existing `__builtin_spirv_Convert<Src>To<E4M3|E5M2>EXT` interface. When `_sat` is present, the resulting `OpFConvert` is decorated with `SaturatedToLargestFloat8NormalConversionEXT`. AI-assisted: Claude Opus 4.7 (commercial SaaS)

…` decoration (#3767) Add round-trip handling for `SPV_EXT_float8`'s saturating FP-to-FP8 conversion. At the LLVM IR level it is represented via `_sat` suffix on the existing `__builtin_spirv_Convert<Src>To<E4M3|E5M2>EXT` interface. When `_sat` is present, the resulting `OpFConvert` is decorated with `SaturatedToLargestFloat8NormalConversionEXT`. AI-assisted: Claude Opus 4.7 (commercial SaaS)

vmaksimo added 2 commits June 2, 2026 03:57

clang-format

0c81b6a

vmaksimo closed this Jun 3, 2026

vmaksimo reopened this Jun 3, 2026

vmaksimo requested review from MrSidims, maarquitos14 and svenvh June 3, 2026 16:08

MrSidims approved these changes Jun 8, 2026

View reviewed changes

vmaksimo requested a review from YuriPlyakhin June 8, 2026 17:04

YuriPlyakhin reviewed Jun 8, 2026

View reviewed changes

Comment thread lib/SPIRV/SPIRVReader.cpp Outdated

YuriPlyakhin mentioned this pull request Jun 8, 2026

[SYCL] Implement sycl_ext_oneapi_fp8 for CRI intel/llvm#21568

Merged

YuriPlyakhin reviewed Jun 9, 2026

View reviewed changes

Comment thread lib/SPIRV/SPIRVReader.cpp Outdated

YuriPlyakhin reviewed Jun 9, 2026

View reviewed changes

Comment thread lib/SPIRV/SPIRVWriter.cpp Outdated

YuriPlyakhin reviewed Jun 9, 2026

View reviewed changes

Comment thread test/extensions/INTEL/SPV_INTEL_fp_conversions/spv_intel_fp_conversions.ll Outdated

vmaksimo requested a review from YuriPlyakhin June 9, 2026 14:47

YuriPlyakhin reviewed Jun 10, 2026

View reviewed changes

YuriPlyakhin approved these changes Jun 10, 2026

View reviewed changes

Merge remote-tracking branch 'origin/main' into HEAD

269840e

vmaksimo merged commit 31301b1 into KhronosGroup:main Jun 11, 2026
9 checks passed

vmaksimo mentioned this pull request Jun 24, 2026

[Backport to 22] Fix spir_func CC, SPV_EXT_float8 saturation decoration, SPV_INTEL_fp_conversions spec update #3788

Merged

vmaksimo mentioned this pull request Jun 25, 2026

[Backport to 21] Fix spir_func CC, SPV_EXT_float8 saturation decoration, SPV_INTEL_fp_conversions spec update #3789

Merged

		@@ -0,0 +1,56 @@
		; Clamping FP-to-FP8 conversions: when SPV_EXT_float8 is enabled, the

Uh oh!

Conversation

vmaksimo commented Jun 1, 2026

Uh oh!

MrSidims commented Jun 1, 2026

Uh oh!

vmaksimo commented Jun 1, 2026

Uh oh!

MrSidims commented Jun 1, 2026

Uh oh!

vmaksimo commented Jun 2, 2026

Uh oh!

MrSidims left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

YuriPlyakhin left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants