Implement extension SPV_KHR_float_controls2 #3475

jmmartinez · 2025-12-17T16:46:02Z

First attempt at implementing SPV_KHR_float_controls2.

Some highlights:

When doing SPIRV->LLVM-IR, we first read the ExecutionModeFPFastMathDefault for every kernel, and if instructions in that kernel do not specify a particular FPFastMathMode, we use the kernel one (question below).
According to SPV_KHR_float_controls2#issues; we do not have an equivalent of LLVM's afn flag. If we map fadd fast float %a, %b to SPIRV and back, it becomes fadd reassoc nnan ninf nsz arcp contract float %a, %b losing the afn flag.

Some questions:

Since not all functions are kernels; what happens when a kernel calls a function with the FPFastMathMode? Should we propagate the attribute down to the callees?
- From the SPEC: The execution model and any execution modes associated with an entry point apply to the entire static function call graph rooted at that entry point. This rule implies that a function appearing in both call graphs of two distinct entry points may behave differently in each case.
This patch doesn't set an ExecutionModeFPFastMathDefault when writing SPIRV. Instead it writes the appropriate FPFastMathMode for every instruction. In that case, should we emit a "zero" FPFastMathMode for instructions without any fast-math-flags ?

MrSidims · 2025-12-18T11:31:30Z

Should we propagate the attribute down to the callees?

We shouldn't, as you have quoted: "This rule implies that a function appearing in both call graphs of two distinct entry points may behave differently in each case.". Runtime should be able to pass fast math controls from a caller to a callee.

In that case, should we emit a "zero" FPFastMathMode for instructions without any fast-math-flags

I'm a bit worried about bloating size of SPIR-V modules in this case. In general I'd suggest to align behaviour of the translator and SPIR-V backend in areas where it's possible. So I'd expect llvm-spirv's implementation resulting in the same SPIR-V as llvm/llvm-project#146941 aka there should be FPFastMathDefault set.

maarquitos14 · 2025-12-18T14:50:46Z

I'll go on vacation in a few hours, and I'm afraid I will not have time to review this before I leave. Feel free to merge this without my approval, and I'll make sure I review when I'm back, even if it's a post-merge review.

I did want to bring up a couple of related issues, though. Hopefully they can be resolved by this PR.

jmmartinez · 2025-12-18T14:51:07Z

Should we propagate the attribute down to the callees?

We shouldn't, as you have quoted: "This rule implies that a function appearing in both call graphs of two distinct entry points may behave differently in each case.". Runtime should be able to pass fast math controls from a caller to a callee.

Then the current implementation should be good, since it doesn't propagate anything.

In that case, should we emit a "zero" FPFastMathMode for instructions without any fast-math-flags

I'm a bit worried about bloating size of SPIR-V modules in this case. In general I'd suggest to align behavior of the translator and SPIR-V backend in areas where it's possible. So I'd expect llvm-spirv's implementation resulting in the same SPIR-V as llvm/llvm-project#146941 aka there should be FPFastMathDefault set.

I see. Then I should fix this implementation to always emit a FPFastMathDefault with all flags set to 0 for every kernel. Right?

test/transcoding/fadd.ll

jmmartinez · 2025-12-22T14:58:47Z

In that case, should we emit a "zero" FPFastMathMode for instructions without any fast-math-flags

I'm a bit worried about bloating size of SPIR-V modules in this case. In general I'd suggest to align behavior of the translator and SPIR-V backend in areas where it's possible. So I'd expect llvm-spirv's implementation resulting in the same SPIR-V as llvm/llvm-project#146941 aka there should be FPFastMathDefault set.

I see. Then I should fix this implementation to always emit a FPFastMathDefault with all flags set to 0 for every kernel. Right?

I've addressed this in b691977 . This commit emits an FPFastMathDefault with all flags set to 0 for every kernel.

jmmartinez · 2025-12-22T15:00:53Z

Fix reassoc flag translation #3125

This one is tricky. reassoc maps to AllowTransform; but AllowTransform requires AllowReassoc and AllowContract to be set. So AllowTransform maps back to reassoc contract.

id decorated twice with the same decoration #3410

I've added a commit related to this, but I'll file a separate patch since this issue is not related to the float_controls2 extension.

MrSidims · 2025-12-22T20:58:28Z

I've added a commit related to this, but I'll file a separate patch since this issue is not related to the float_controls2 extension.

Fine with me.

Most (if not all) of the folks working on the translator are currently on holidays (including myself), so guess review will be done a bit later :)

(unless there is a super urgency - in this case I can take a look before New Year)

jmmartinez · 2025-12-23T08:23:05Z

I've added a commit related to this, but I'll file a separate patch since this issue is not related to the float_controls2 extension.

Fine with me.

Most (if not all) of the folks working on the translator are currently on holidays (including myself), so guess review will be done a bit later :)

(unless there is a super urgency - in this case I can take a look before New Year)

No problem! It's not urgent.

lib/SPIRV/SPIRVWriter.cpp

test/extensions/KHR/SPV_KHR_float_controls2/execution_mode_default.ll

test/transcoding/fadd.ll

test/fp-decorate-twice.ll

MrSidims

LGTM

I'd like to hear from @maarquitos14 before merging.

jmmartinez · 2026-01-07T13:13:07Z

Just in case, I'd like to bring the attention to one of my previous messages about the issue #3125 :

Currently, this PR maps LLVM's reassoc -> AllowReassoc (this is the behavior that was implemented before float_controls2).

In the issue it is suggested that we'd better translate reassoc -> AllowTransform. The problem with this is that AllowTransform implies both AllowContract and AllowReassoc.

Then, if we map LLVM's to SPIRV and back to LLVM we end up with different semantics:

reassoc -> AllowTransform AllowContract AllowReassoc -> contract reassoc

To avoid this, we could translate

reassoc -> AllowReassoc -> no-flags
contract reassoc -> AllowTransform AllowContract AllowReassoc -> contract reassoc

MrSidims · 2026-01-07T13:18:02Z

Currently, this PR maps LLVM's reassoc -> AllowReassoc (this is the behavior that was implemented before float_controls2).

Thanks for bringing the attention back. I believe we should do one thing at a time and fix behaviour in unrelated to this PR patch.

maarquitos14 · 2026-01-08T16:31:32Z

LGTM

I'd like to hear from @maarquitos14 before merging.

I plan to look at this today/tomorrow.

maarquitos14 · 2026-01-08T18:11:46Z

I've added a commit related to this, but I'll file a separate patch since this issue is not related to the float_controls2 extension

That works for me, thanks. Just highlighted it here to make sure it worked well with the current implementation.

maarquitos14 · 2026-01-08T18:14:06Z

Currently, this PR maps LLVM's reassoc -> AllowReassoc (this is the behavior that was implemented before float_controls2).

Thanks for bringing the attention back. I believe we should do one thing at a time and fix behaviour in unrelated to this PR patch.

@jmmartinez ping me if you do create a separate patch for this.

maarquitos14

First pass. I'll do a second pass to check tests.

lib/SPIRV/SPIRVReader.cpp

lib/SPIRV/SPIRVReader.h

lib/SPIRV/SPIRVReader.cpp

lib/SPIRV/SPIRVWriter.cpp

maarquitos14 · 2026-01-08T18:36:26Z

lib/SPIRV/SPIRVWriter.cpp


+      case spv::ExecutionModeSignedZeroInfNanPreserve:
+        // With SPV_KHR_float_controls2 this is deprecated
+        if (BM->hasCapability(CapabilityFloatControls2))


Don't we need to add FPFastMathDefault execution mode too? It is required to set the equivalent of SignedZeroInfNanPreserve, isn't it?

At the moment, since the default fast-math flags are all disabled, both are preserved (ContractionOff/SignedZeroInfNanPreserve disable the contract/nsz ninf nnan flags).

I should add a comment explaining how these are preserved.

Okay, I see what you mean. However, I vaguely recall that having no flags isn't the same as having all flags set to zero from my implementation of this extension in the SPIRV BE. Let me try and find that again.

Also, a comment would help anyway :)

If an operation is decorated with FPFastMathMode then the flags from that decoration apply. Otherwise, if the current entry point sets any FPFastMathDefault execution mode then all flags specified for any operand type or for the result type of the operation apply. If the operation is not decorated with FPFastMathMode and the entry point sets no FPFastMathDefault execution modes then the flags to be applied are determined by the client API and not by SPIR-V.

My understanding of this quote from the spec is that no decoration is not the same than decoration with all flags set to zero: all flags set to zero clearly specify the fast math mode, while no decoration means the client API can decide. Do you agree?

I agree.

Currently, if float_controls2 is available, we enable it always with all the flags set to zero. Then an LLVM floating-point operation with no flags has the same semantics in SPIRV.
However, I think there is a problem in my implementation: functions getting called by kernels.

Currently the FastMathModeDefault are not preserved when doing spirv->llvm-ir->spirv. When doing spirv->llvm-ir we set the FastMathModeDefault into the kernel operations, but we cannot do that on the called functions. Then, when doing llvm-ir->spirv we end up with the right flags on the kernel, but stricter flags (all set to 0 propagated through the new FastMathModeDefault) on the called function.

Just a second contradicting thought. In fact, depending on how you see it, setting no flags in SPIRV can also be seen as enabling all rewrite flags in LLVM: contract / reassociate / ... are all permitted and is up to the client to decide if it optimizes it or not.

Exactly, setting everything to zero might prevent possible client optimizations. I think we shouldn't do that.

Updated the PR. With f8ace92 we preserve the flags.

From SPIRV->LLVM we preserve the FastMathModeDefault in the !spirv.ExecutionMode metadata. Then when doing LLVM->SPIRV the metadata is lowered into the original FastMathModeDefault.

We set the default execution to 0 only when:

FastMathModeDefault in !spirv.ExecutionMode was 0 to begin with

We're adding the ContractionOff ExecutionMode

We're adding the SignedZeroInfNanPreserve

For these last 2, since these execution-modes are deprecated with FloatControls2, we have to translate them to something equivalent. We cannot unset some flags and leave others for the client API. For simplicity, I've chosen to set all the flags to 0.
This can be argued though.

In both cases, I've chosen to preserve the fast-math flags that are attached to the instructions. (Fadd with contract flags will still be translated to fadd contract even if ContracitonOff was set).

lib/SPIRV/SPIRVWriter.cpp

lib/SPIRV/libSPIRV/SPIRVEntry.h

maarquitos14 · 2026-01-09T10:59:23Z

test/extensions/KHR/SPV_KHR_float_controls2/execution_mode_default.ll

+entry:
+  ; IR-LABEL: define {{.*}} @foo
+  ; IR-NEXT: entry:
+  ; IR-NEXT:   %rh = fadd contract half %ah, %bh


My understanding is that you don't check decorations in SPIRV because you assume that they have to be present in SPIRV if they are present in the reverse translation. Am I right?

Sort of. I wanted to check only that the ExecutionModeId was set correctly (the flags set on the instructions are verified in other tests). And reverse translated it to ensure the contract flag doesn't get overridden by it.

I can add the checks for the individual instructions if it make more sense.

As long as the intent is clearly specified in the test, I'm happy with that. Can you add a comment explaining this?

Added:

; By default, do not set the execution-mode when the extension is used. ; This test doesn't verify directly that the instructions have the SPIRV ; 'contract' flag (this is done in another test). ; As a sanity check, we still reverse-translate and check the IR.

test/extensions/KHR/SPV_KHR_float_controls2/execution_mode_id.spvasm

lib/SPIRV/SPIRVWriter.cpp

test/extensions/KHR/SPV_KHR_float_controls2/execution_mode_default.ll

test/extensions/KHR/SPV_KHR_float_controls2/extension_not_needed.ll

test/extensions/KHR/SPV_KHR_float_controls2/extension_not_needed_but_used.ll

jmmartinez · 2026-01-19T15:22:44Z

lib/SPIRV/SPIRVReader.cpp

+  // Get the scalar type to handle vector operands. And get the first operand
+  // type (instead of the result) due to fcmp instructions.
+  Type *FloatType = Inst->getOperand(0)->getType()->getScalarType();
+  auto Func2FMF = FuncToFastMathFlags.find({Inst->getFunction(), FloatType});


I'm tempted to remove this FuncToFastMathFlags stuff.

It's used to set the FPFastMathFlags that are attached to the execution mode to the individual instructions of a kernel.

But since we're preserving the FPFastMathFlags in the metadata; I'm thinking that this is not needed anymore.

@maarquitos14 should I remove this ?

I believe that this logic should be still placed somewhere as the middleend and backend are unlikely to know about this metadata out of the box and honestly it feels like for optimization passes it's easier to work with individual instruction flags. IMHO resolving ExecutionMode to FP flag right away in the SPIR-V consumer won't harm and actually make implementation lower-level drivers friendly.

@svenvh @vmaksimo WDYT?

MrSidims

Functionally LGTM, but lets make tests passing :)

test/extensions/KHR/SPV_KHR_float_controls2/execution_mode_contract_off.ll

MrSidims · 2026-01-22T13:22:49Z

test/extensions/KHR/SPV_KHR_float_controls2/execution_mode_contract_off.ll

+; SPIRV-ON-DAG: ExecutionModeId [[FOO]] 6028 [[HALF:[0-9]+]] [[ZERO:[0-9]+]]
+; SPIRV-ON-DAG: ExecutionModeId [[FOO]] 6028 [[FLOAT:[0-9]+]] [[ZERO]]
+; SPIRV-ON-DAG: ExecutionModeId [[FOO]] 6028 [[DOUBLE:[0-9]+]] [[ZERO]]
+; SPIRV-ON-DAG: TypeFloat [[HALF]] 16


Test is currently failing, not 100% why. May be we should move this line before checks of ExecutionModeId to ensure correct REGEX variables definition:

; SPIRV-ON-DAG: TypeFloat [[#HALF:]] 16 ... ; SPIRV-ON-DAG: ExecutionModeId [[#FOO]] 6028 [[#HALF]] [[#ZERO]]

It's weird. I haven't managed to reproduce the issue. But I think I know what the problem is: I'm scanning the TypeMap and there is no guarantee of the order of its elements. I'll fix this to always generate the same code.

Fixed in the last commit by sorting the floating-point types by bit-width and encoding.

jmmartinez · 2026-01-22T14:38:36Z

Functionally LGTM, but lets make tests passing :)

My bad ! In my defense... It passed in my machine. There was one matrix test failing though (but also over main so I didn't look much into it).

With this extension, the execution modes `ContractionOff and `SignedZeroInfNanPreserve` are deprecated and we should use `FPFastMathDefault` instead. Additionally, the `FPFastMathMode` mode `Fast` bit is also deprecated.

KhronosGroup#3410

…t.ll

…hDefault

Before, the extension would be used only when an operation having fast-math flags that can only be represented using float_controls2 was enabled. Afer this patch, the extension is added if floating-point types are used in the module.

…tractionOff and SignedZeroInfNanPreserve to FPFastMathDefault 0

MrSidims requested review from MrSidims, maarquitos14, svenvh and vmaksimo and removed request for vmaksimo December 18, 2025 11:20

jmmartinez commented Dec 18, 2025

View reviewed changes

test/transcoding/fadd.ll Show resolved Hide resolved

jmmartinez force-pushed the users/jmmartinez/spv_khr_float_controls2 branch from cd6a10d to 57840f3 Compare December 22, 2025 15:42

MrSidims reviewed Jan 2, 2026

View reviewed changes

jmmartinez force-pushed the users/jmmartinez/spv_khr_float_controls2 branch from 14519f7 to 8fa049e Compare January 5, 2026 12:40

MrSidims approved these changes Jan 7, 2026

View reviewed changes

jmmartinez force-pushed the users/jmmartinez/spv_khr_float_controls2 branch from 8fa049e to dd4806c Compare January 8, 2026 16:11

maarquitos14 reviewed Jan 8, 2026

View reviewed changes

maarquitos14 reviewed Jan 9, 2026

View reviewed changes

jmmartinez force-pushed the users/jmmartinez/spv_khr_float_controls2 branch 3 times, most recently from 2abce3e to 1108325 Compare January 19, 2026 15:14

jmmartinez commented Jan 19, 2026

View reviewed changes

MrSidims requested review from MrSidims and maarquitos14 January 22, 2026 13:05

MrSidims approved these changes Jan 22, 2026

View reviewed changes

jmmartinez added 22 commits January 23, 2026 15:33

Implement extension SPV_KHR_float_controls2

7ca5c71

With this extension, the execution modes `ContractionOff and `SignedZeroInfNanPreserve` are deprecated and we should use `FPFastMathDefault` instead. Additionally, the `FPFastMathMode` mode `Fast` bit is also deprecated.

[Review] set FPFastMathDefault equal to 0 for every entry-point

bd74ca9

[Review] Add test showing reassoc->AllowTransform->reassoc contract

d0d26f2

[Review] add fcmp and ExtInst tests

2b25d20

Ignore FPFastMathMode decorations attached as metadata

08aee52

KhronosGroup#3410

Add test with multiple floating point types

03e9a61

[Review] reword FPFastMathMode decoration metadata comment

e8eb865

[Review] fix typo in execution_mode_default.ll

97211a8

[Review] rename CHECK->SPIRV in execution_mode_default.ll

d58da85

[Review] add reverse translation tests for execution_mode_default.ll

7321ab2

[Review] remove word-count from SPIRV checks in execution_mode_defaul…

0f02365

…t.ll

[Review] remove word-count from SPIRV checks in fp-decorate-twice.ll

fe86d9c

[Review] Pre-commit tests before changing the logic of transFPFastMat…

48424af

…hDefault

[Review] Update transFPFastMathDefault

49600ab

Before, the extension would be used only when an operation having fast-math flags that can only be represented using float_controls2 was enabled. Afer this patch, the extension is added if floating-point types are used in the module.

[Review][NFC] Comments and renames

e7f4886

[Review][NFC] Add assertions

1802fde

[Review] Propagate FP mode to vector types

4967f1c

[Review] missing space

97c9d7a

[Review] missing .

5e6e80b

[Review] operaiton -> operation

b1b0d71

[Review] Do not set FPFastMathDefault to 0 by default / translate Con…

437daf5

…tractionOff and SignedZeroInfNanPreserve to FPFastMathDefault 0

[Review] make tests more reliable

ebdcd76

jmmartinez force-pushed the users/jmmartinez/spv_khr_float_controls2 branch from 1108325 to ebdcd76 Compare January 23, 2026 15:19

[Review] Emit the FastMathDefaultMode in a consistent order

2c6901c

jmmartinez force-pushed the users/jmmartinez/spv_khr_float_controls2 branch from 9633e0d to 2c6901c Compare January 23, 2026 15:39

Implement extension SPV_KHR_float_controls2 #3475

Are you sure you want to change the base?

Implement extension SPV_KHR_float_controls2 #3475

Conversation

jmmartinez commented Dec 17, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

MrSidims commented Dec 18, 2025

Uh oh!

maarquitos14 commented Dec 18, 2025

Uh oh!

jmmartinez commented Dec 18, 2025

Uh oh!

Uh oh!

jmmartinez commented Dec 22, 2025

Uh oh!

jmmartinez commented Dec 22, 2025

Uh oh!

MrSidims commented Dec 22, 2025

Uh oh!

jmmartinez commented Dec 23, 2025

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

MrSidims left a comment

Choose a reason for hiding this comment

Uh oh!

jmmartinez commented Jan 7, 2026

Uh oh!

MrSidims commented Jan 7, 2026

Uh oh!

maarquitos14 commented Jan 8, 2026

Uh oh!

maarquitos14 commented Jan 8, 2026

Uh oh!

maarquitos14 commented Jan 8, 2026

Uh oh!

maarquitos14 left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

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!

Choose a reason for hiding this comment

Uh oh!

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!

Uh oh!

jmmartinez commented Dec 17, 2025 •

edited

Loading