Skip to content

[SYCL][Doc] Minor tweaks to SPV_INTEL_function_variants #19782

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 3 commits into
base: sycl
Choose a base branch
from
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Original file line number Diff line number Diff line change
Expand Up @@ -60,8 +60,8 @@ Copyright (c) 2025 Intel Corporation. All rights reserved.

[width="40%",cols="25,25"]
|========================================
| Last Modified Date | 2025-05-08
| Revision | 0.11
| Last Modified Date | 2025-08-13
| Revision | 0.12
|========================================


Expand Down Expand Up @@ -253,7 +253,7 @@ If the *{spec_capability_name}* capability is declared:
*OpName* or *OpMemberName* referencing the instruction are removed.
** The decoration itself is removed.

* If all 'Condition' operands of *{conditional_copy_name}* have been specialized to a known value, replace *{conditional_copy_name}* with *OpCopyObject* using the 'Operand' whose 'Condition' is *true*.
* If all 'Condition' operands of *{conditional_copy_name}* have been specialized to a known value, replace *{conditional_copy_name}* with *OpCopyObject* using the first 'Operand' whose 'Condition' is *true*.

* If the module does not contain any decorations or instructions defined by this extension, any present *OpCapability {spec_capability_name}*, *OpCapability {fnvar_capability_name}* or *OpExtension {extension_name}* instructions are removed.

Expand Down Expand Up @@ -476,7 +476,7 @@ See *Specialization*.
1+|Capability: +
*{fnvar_capability_name}*

| 4 + variable | {spec_const_capabilities_token}
| 3 + variable | {spec_const_capabilities_token}
| '<id>' +
'Result Type'
| 'Result <id>'
Expand All @@ -494,7 +494,7 @@ Add to Section 3.56.9, Function Instructions:
+
Make a copy of 'Operand X' if 'Condition X' is *true*.

From all 'Condition X'-'Operand X' pairs, 'exactly' one 'Condition X' must be *true*. Consequently, at least one 'Condition X'-'Operand X' pair must be present.
From all 'Condition X'-'Operand X' pairs, at least one 'Condition X' must be *true*. Consequently, at least one 'Condition X'-'Operand X' pair must be present.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In the uses cases I can think of, setting more than one Condition X to true would indicate that something went wrong. What is the rationale for allowing this and arbitrarily using the first condition? Should we instead say this is not allowed and add a validation check?


Each 'Condition X' must be the result of a specialization constant of scalar 'Boolean' type.

Expand All @@ -505,7 +505,7 @@ Add to Section 3.56.9, Function Instructions:
1+|Capability: +
*{spec_capability_name}*

| 5 + variable | {conditional_copy_token}
| 3 + variable | {conditional_copy_token}
| '<id>' +
'Result Type'
| 'Result <id>'
Expand Down Expand Up @@ -762,4 +762,5 @@ Given the target `x86_64`, features `avx2,avx512f` and architecture `intel_cpu_s
|0.9|2025-04-02|Jakub Žádník|Add conditional extension and specialization by capabilities
|0.10|2025-04-22|Jakub Žádník|Added more precise wording regarding architecture comparisons
|0.11|2025-05-08|Jakub Žádník|Misc corrections and clarifications
|0.12|2025-08-13|Jakub Žádník|Fix word counts to match consumer impl; Allow multiple true conditional copy conditions
|========================================