Use SPV_EXT_long_vector extension for non-standard vector size by Qi-Ye-079 · Pull Request #3777 · KhronosGroup/SPIRV-LLVM-Translator

Qi-Ye-079 · 2026-06-10T15:56:14Z

For a vector type, add SPV_EXT_long_vector extension and prioritize it over SPV_INTEL_vector_compute whenever the vector type doesn't have a standard component size (2, 3, 4, 8, or 16).

MrSidims · 2026-06-10T21:57:04Z

keep using SPV_INTEL_vector_compute for other non-standard vector size at the moment.

Multi-vendor extension must always have bigger priority, than a vendor extension if they do the same.

Qi-Ye-079 · 2026-06-23T21:02:00Z

keep using SPV_INTEL_vector_compute for other non-standard vector size at the moment.

Multi-vendor extension must always have bigger priority, than a vendor extension if they do the same.

Yes, I'm prioritizing SPV_EXT_long_vector over intel one now.

vmaksimo

LGTM
Nit: I'd add test case for a vector of arbitrary size (now we have only for 1-element vector.)

MrSidims · 2026-06-24T10:33:53Z

+    unsigned NumElements = VecTy->getNumElements();
+    bool IsNonStandardCount =
+        !(NumElements == 2 || NumElements == 3 || NumElements == 4 ||
+          NumElements == 8 || NumElements == 16);
+    if (IsNonStandardCount &&
+        !BM->isAllowedToUseExtension(ExtensionID::SPV_EXT_long_vector) &&
+        !BM->isAllowedToUseExtension(ExtensionID::SPV_INTEL_vector_compute)) {
+      BM->getErrorLog().checkError(
+          false, SPIRVEC_RequiresExtension,
+          "SPV_EXT_long_vector or SPV_INTEL_vector_compute\n"
+          "NOTE: LLVM module contains a vector with an unsupported number of "
+          "components, translation of which requires one of these extensions");
+      return nullptr;
+    }


Why have we started to need this?

I've answered same the question for @vmaksimo : the same check in SRIRVType::validate() is done by assert enclosed by #ifndef NDEBUG block only; I thought adding this check should be more user friendly and make it easier for lit test.
Actually I think this piece of code should replace the assertion check in SPIRVType::validate() instead, but... I don't know if it can break anything or have any side effect by with such change.
If you think this is purely redundant or can cause regression, I'm ok to remove it.

sounds reasonable to me. But I'm fine either way, I don't think it should block this PR.

svenvh · 2026-06-25T09:15:40Z

Nit: I'd add test case for a vector of arbitrary size (now we have only for 1-element vector.)

Yes, I was going to suggest the same. I'd suggest to simply add another case to each test file.

Qi-Ye-079 · 2026-06-25T14:56:30Z

Nit: I'd add test case for a vector of arbitrary size (now we have only for 1-element vector.)

Yes, I was going to suggest the same. I'd suggest to simply add another case to each test file.

I agree adding another arbitrary size for each test, but since the emission of OpExtension is done per module, and there's no usage of split-file in this repo, I think it's better to add new files for a new arbitrary size, to ensure each different size actually emits the correct extension and capability (or report error).

vmaksimo · 2026-06-25T15:46:44Z

keep using SPV_INTEL_vector_compute for other non-standard vector size at the moment.

Multi-vendor extension must always have bigger priority, than a vendor extension if they do the same.

Note, we want to rely on SPV_INTEL_vector_compute for vector compute modules (ESIMD) even when SPV_EXT_long_vector is enabled.
I suggest this PR stays community-valuable, and I will publish INTEL-only related change in a separate PR.

vmaksimo

I'd merge vector_size_5,ll and negative_size_5.ll into one test, same for size 1.
Other than that, LGTM

YuriPlyakhin

LGTM. Few nits. And another nit: I would merge some of those tests, e.g. 2 negative into single test, 2 priority tests into single test, two size 5 and size 1 tests into single test.

Qi-Ye-079 · 2026-06-30T14:35:52Z

LGTM. Few nits. And another nit: I would merge some of those tests, e.g. 2 negative into single test, 2 priority tests into single test, two size 5 and size 1 tests into single test.

@YuriPlyakhin Thanks for the review. I actually split them into different files on purpose, see this comment I replied to Sven: #3777 (comment)

Qi-Ye-079

@vmaksimo @YuriPlyakhin Thanks, I've fixed all nits.

vmaksimo · 2026-06-30T19:25:44Z

@svenvh @MrSidims would be nice if one of you'd be able to take a look so we don't merge it with Intel approvals only🙂

YuriPlyakhin · 2026-07-07T16:50:20Z

Planning to merge tomorrow unless anyone objects. Friendly ping @svenvh / @MrSidims / @maarquitos14

maarquitos14

Just a nit, otherwise LGTM.

#3829) #3777 added `SPV_EXT_long_vector` and gave it priority over `SPV_INTEL_vector_compute`: when both extensions are enabled and a vector has a non-standard component count, the translator now emits `CapabilityLongVectorEXT` instead of `CapabilityVectorAnyINTEL`. This regresses `VectorCompute` modules. The offloading flow (producing both `VectorCompute` and non-`VectorCompute` modules) applies a single, fixed extension list uniformly to every device image, so a `VectorCompute` module is translated with both `SPV_INTEL_vector_compute` and `SPV_EXT_long_vector` enabled. Before #3777 such a module emitted `VectorAnyINTEL` for its non-standard vectors; after #3777 it emits `LongVectorEXT`. `VectorCompute` consumers require `VectorAnyINTEL`, so this is a functional regression. Hence, the enabled extension list does not identify a module as `VectorCompute` - the `VectorCompute` metadata (`VCFunction` /`VCGlobalVariable`) does. `IsVectorComputeModule` records the presence of that metadata before type translation. `VectorCompute` modules keep using `VectorAnyINTEL`, restoring the pre-#3777 behavior; all other modules still prefer the multi-vendor `LongVectorEXT` when its extension is enabled. --------- Co-authored-by: Ye, Qi <qi.ye@intel.com>

…ector size (KhronosGroup#3777) For a vector type, add `SPV_EXT_long_vector` extension and prioritize it over `SPV_INTEL_vector_compute` whenever the vector type doesn't have a standard component size (2, 3, 4, 8, or 16). [Backport to 22] Keep VectorAnyINTEL for VectorCompute modules with SPV_EXT_long_vector (KhronosGroup#3829) KhronosGroup#3777 added `SPV_EXT_long_vector` and gave it priority over `SPV_INTEL_vector_compute`: when both extensions are enabled and a vector has a non-standard component count, the translator now emits `CapabilityLongVectorEXT` instead of `CapabilityVectorAnyINTEL`. This regresses `VectorCompute` modules. The offloading flow (producing both `VectorCompute` and non-`VectorCompute` modules) applies a single, fixed extension list uniformly to every device image, so a `VectorCompute` module is translated with both `SPV_INTEL_vector_compute` and `SPV_EXT_long_vector` enabled. Before KhronosGroup#3777 such a module emitted `VectorAnyINTEL` for its non-standard vectors; after KhronosGroup#3777 it emits `LongVectorEXT`. `VectorCompute` consumers require `VectorAnyINTEL`, so this is a functional regression. Hence, the enabled extension list does not identify a module as `VectorCompute` - the `VectorCompute` metadata (`VCFunction` /`VCGlobalVariable`) does. `IsVectorComputeModule` records the presence of that metadata before type translation. `VectorCompute` modules keep using `VectorAnyINTEL`, restoring the pre-KhronosGroup#3777 behavior; all other modules still prefer the multi-vendor `LongVectorEXT` when its extension is enabled.

…ector size (KhronosGroup#3777) For a vector type, add `SPV_EXT_long_vector` extension and prioritize it over `SPV_INTEL_vector_compute` whenever the vector type doesn't have a standard component size (2, 3, 4, 8, or 16). [Backport to 21] Keep VectorAnyINTEL for VectorCompute modules with SPV_EXT_long_vector (KhronosGroup#3829) KhronosGroup#3777 added `SPV_EXT_long_vector` and gave it priority over `SPV_INTEL_vector_compute`: when both extensions are enabled and a vector has a non-standard component count, the translator now emits `CapabilityLongVectorEXT` instead of `CapabilityVectorAnyINTEL`. This regresses `VectorCompute` modules. The offloading flow (producing both `VectorCompute` and non-`VectorCompute` modules) applies a single, fixed extension list uniformly to every device image, so a `VectorCompute` module is translated with both `SPV_INTEL_vector_compute` and `SPV_EXT_long_vector` enabled. Before KhronosGroup#3777 such a module emitted `VectorAnyINTEL` for its non-standard vectors; after KhronosGroup#3777 it emits `LongVectorEXT`. `VectorCompute` consumers require `VectorAnyINTEL`, so this is a functional regression. Hence, the enabled extension list does not identify a module as `VectorCompute` - the `VectorCompute` metadata (`VCFunction` /`VCGlobalVariable`) does. `IsVectorComputeModule` records the presence of that metadata before type translation. `VectorCompute` modules keep using `VectorAnyINTEL`, restoring the pre-KhronosGroup#3777 behavior; all other modules still prefer the multi-vendor `LongVectorEXT` when its extension is enabled.

…ector size (KhronosGroup#3777) For a vector type, add `SPV_EXT_long_vector` extension and prioritize it over `SPV_INTEL_vector_compute` whenever the vector type doesn't have a standard component size (2, 3, 4, 8, or 16). [Backport to 20] Keep VectorAnyINTEL for VectorCompute modules with SPV_EXT_long_vector (KhronosGroup#3829) KhronosGroup#3777 added `SPV_EXT_long_vector` and gave it priority over `SPV_INTEL_vector_compute`: when both extensions are enabled and a vector has a non-standard component count, the translator now emits `CapabilityLongVectorEXT` instead of `CapabilityVectorAnyINTEL`. This regresses `VectorCompute` modules. The offloading flow (producing both `VectorCompute` and non-`VectorCompute` modules) applies a single, fixed extension list uniformly to every device image, so a `VectorCompute` module is translated with both `SPV_INTEL_vector_compute` and `SPV_EXT_long_vector` enabled. Before KhronosGroup#3777 such a module emitted `VectorAnyINTEL` for its non-standard vectors; after KhronosGroup#3777 it emits `LongVectorEXT`. `VectorCompute` consumers require `VectorAnyINTEL`, so this is a functional regression. Hence, the enabled extension list does not identify a module as `VectorCompute` - the `VectorCompute` metadata (`VCFunction` /`VCGlobalVariable`) does. `IsVectorComputeModule` records the presence of that metadata before type translation. `VectorCompute` modules keep using `VectorAnyINTEL`, restoring the pre-KhronosGroup#3777 behavior; all other modules still prefer the multi-vendor `LongVectorEXT` when its extension is enabled.

…ector size (KhronosGroup#3777) For a vector type, add `SPV_EXT_long_vector` extension and prioritize it over `SPV_INTEL_vector_compute` whenever the vector type doesn't have a standard component size (2, 3, 4, 8, or 16). [Backport to 19] Keep VectorAnyINTEL for VectorCompute modules with SPV_EXT_long_vector (KhronosGroup#3829) KhronosGroup#3777 added `SPV_EXT_long_vector` and gave it priority over `SPV_INTEL_vector_compute`: when both extensions are enabled and a vector has a non-standard component count, the translator now emits `CapabilityLongVectorEXT` instead of `CapabilityVectorAnyINTEL`. This regresses `VectorCompute` modules. The offloading flow (producing both `VectorCompute` and non-`VectorCompute` modules) applies a single, fixed extension list uniformly to every device image, so a `VectorCompute` module is translated with both `SPV_INTEL_vector_compute` and `SPV_EXT_long_vector` enabled. Before KhronosGroup#3777 such a module emitted `VectorAnyINTEL` for its non-standard vectors; after KhronosGroup#3777 it emits `LongVectorEXT`. `VectorCompute` consumers require `VectorAnyINTEL`, so this is a functional regression. Hence, the enabled extension list does not identify a module as `VectorCompute` - the `VectorCompute` metadata (`VCFunction` /`VCGlobalVariable`) does. `IsVectorComputeModule` records the presence of that metadata before type translation. `VectorCompute` modules keep using `VectorAnyINTEL`, restoring the pre-KhronosGroup#3777 behavior; all other modules still prefer the multi-vendor `LongVectorEXT` when its extension is enabled.

…ector size (KhronosGroup#3777) For a vector type, add `SPV_EXT_long_vector` extension and prioritize it over `SPV_INTEL_vector_compute` whenever the vector type doesn't have a standard component size (2, 3, 4, 8, or 16). [Backport to 18] Keep VectorAnyINTEL for VectorCompute modules with SPV_EXT_long_vector (KhronosGroup#3829) KhronosGroup#3777 added `SPV_EXT_long_vector` and gave it priority over `SPV_INTEL_vector_compute`: when both extensions are enabled and a vector has a non-standard component count, the translator now emits `CapabilityLongVectorEXT` instead of `CapabilityVectorAnyINTEL`. This regresses `VectorCompute` modules. The offloading flow (producing both `VectorCompute` and non-`VectorCompute` modules) applies a single, fixed extension list uniformly to every device image, so a `VectorCompute` module is translated with both `SPV_INTEL_vector_compute` and `SPV_EXT_long_vector` enabled. Before KhronosGroup#3777 such a module emitted `VectorAnyINTEL` for its non-standard vectors; after KhronosGroup#3777 it emits `LongVectorEXT`. `VectorCompute` consumers require `VectorAnyINTEL`, so this is a functional regression. Hence, the enabled extension list does not identify a module as `VectorCompute` - the `VectorCompute` metadata (`VCFunction` /`VCGlobalVariable`) does. `IsVectorComputeModule` records the presence of that metadata before type translation. `VectorCompute` modules keep using `VectorAnyINTEL`, restoring the pre-KhronosGroup#3777 behavior; all other modules still prefer the multi-vendor `LongVectorEXT` when its extension is enabled.

…ector size (KhronosGroup#3777) For a vector type, add `SPV_EXT_long_vector` extension and prioritize it over `SPV_INTEL_vector_compute` whenever the vector type doesn't have a standard component size (2, 3, 4, 8, or 16). [Backport to 17] Keep VectorAnyINTEL for VectorCompute modules with SPV_EXT_long_vector (KhronosGroup#3829) KhronosGroup#3777 added `SPV_EXT_long_vector` and gave it priority over `SPV_INTEL_vector_compute`: when both extensions are enabled and a vector has a non-standard component count, the translator now emits `CapabilityLongVectorEXT` instead of `CapabilityVectorAnyINTEL`. This regresses `VectorCompute` modules. The offloading flow (producing both `VectorCompute` and non-`VectorCompute` modules) applies a single, fixed extension list uniformly to every device image, so a `VectorCompute` module is translated with both `SPV_INTEL_vector_compute` and `SPV_EXT_long_vector` enabled. Before KhronosGroup#3777 such a module emitted `VectorAnyINTEL` for its non-standard vectors; after KhronosGroup#3777 it emits `LongVectorEXT`. `VectorCompute` consumers require `VectorAnyINTEL`, so this is a functional regression. Hence, the enabled extension list does not identify a module as `VectorCompute` - the `VectorCompute` metadata (`VCFunction` /`VCGlobalVariable`) does. `IsVectorComputeModule` records the presence of that metadata before type translation. `VectorCompute` modules keep using `VectorAnyINTEL`, restoring the pre-KhronosGroup#3777 behavior; all other modules still prefer the multi-vendor `LongVectorEXT` when its extension is enabled.

…ector size (KhronosGroup#3777) For a vector type, add `SPV_EXT_long_vector` extension and prioritize it over `SPV_INTEL_vector_compute` whenever the vector type doesn't have a standard component size (2, 3, 4, 8, or 16). [Backport to 16] Keep VectorAnyINTEL for VectorCompute modules with SPV_EXT_long_vector (KhronosGroup#3829) KhronosGroup#3777 added `SPV_EXT_long_vector` and gave it priority over `SPV_INTEL_vector_compute`: when both extensions are enabled and a vector has a non-standard component count, the translator now emits `CapabilityLongVectorEXT` instead of `CapabilityVectorAnyINTEL`. This regresses `VectorCompute` modules. The offloading flow (producing both `VectorCompute` and non-`VectorCompute` modules) applies a single, fixed extension list uniformly to every device image, so a `VectorCompute` module is translated with both `SPV_INTEL_vector_compute` and `SPV_EXT_long_vector` enabled. Before KhronosGroup#3777 such a module emitted `VectorAnyINTEL` for its non-standard vectors; after KhronosGroup#3777 it emits `LongVectorEXT`. `VectorCompute` consumers require `VectorAnyINTEL`, so this is a functional regression. Hence, the enabled extension list does not identify a module as `VectorCompute` - the `VectorCompute` metadata (`VCFunction` /`VCGlobalVariable`) does. `IsVectorComputeModule` records the presence of that metadata before type translation. `VectorCompute` modules keep using `VectorAnyINTEL`, restoring the pre-KhronosGroup#3777 behavior; all other modules still prefer the multi-vendor `LongVectorEXT` when its extension is enabled.

…ector size (KhronosGroup#3777) For a vector type, add `SPV_EXT_long_vector` extension and prioritize it over `SPV_INTEL_vector_compute` whenever the vector type doesn't have a standard component size (2, 3, 4, 8, or 16). [Backport to 15] Keep VectorAnyINTEL for VectorCompute modules with SPV_EXT_long_vector (KhronosGroup#3829) KhronosGroup#3777 added `SPV_EXT_long_vector` and gave it priority over `SPV_INTEL_vector_compute`: when both extensions are enabled and a vector has a non-standard component count, the translator now emits `CapabilityLongVectorEXT` instead of `CapabilityVectorAnyINTEL`. This regresses `VectorCompute` modules. The offloading flow (producing both `VectorCompute` and non-`VectorCompute` modules) applies a single, fixed extension list uniformly to every device image, so a `VectorCompute` module is translated with both `SPV_INTEL_vector_compute` and `SPV_EXT_long_vector` enabled. Before KhronosGroup#3777 such a module emitted `VectorAnyINTEL` for its non-standard vectors; after KhronosGroup#3777 it emits `LongVectorEXT`. `VectorCompute` consumers require `VectorAnyINTEL`, so this is a functional regression. Hence, the enabled extension list does not identify a module as `VectorCompute` - the `VectorCompute` metadata (`VCFunction` /`VCGlobalVariable`) does. `IsVectorComputeModule` records the presence of that metadata before type translation. `VectorCompute` modules keep using `VectorAnyINTEL`, restoring the pre-KhronosGroup#3777 behavior; all other modules still prefer the multi-vendor `LongVectorEXT` when its extension is enabled.

…ector size (KhronosGroup#3777) For a vector type, add `SPV_EXT_long_vector` extension and prioritize it over `SPV_INTEL_vector_compute` whenever the vector type doesn't have a standard component size (2, 3, 4, 8, or 16). [Backport to 14] Keep VectorAnyINTEL for VectorCompute modules with SPV_EXT_long_vector (KhronosGroup#3829) KhronosGroup#3777 added `SPV_EXT_long_vector` and gave it priority over `SPV_INTEL_vector_compute`: when both extensions are enabled and a vector has a non-standard component count, the translator now emits `CapabilityLongVectorEXT` instead of `CapabilityVectorAnyINTEL`. This regresses `VectorCompute` modules. The offloading flow (producing both `VectorCompute` and non-`VectorCompute` modules) applies a single, fixed extension list uniformly to every device image, so a `VectorCompute` module is translated with both `SPV_INTEL_vector_compute` and `SPV_EXT_long_vector` enabled. Before KhronosGroup#3777 such a module emitted `VectorAnyINTEL` for its non-standard vectors; after KhronosGroup#3777 it emits `LongVectorEXT`. `VectorCompute` consumers require `VectorAnyINTEL`, so this is a functional regression. Hence, the enabled extension list does not identify a module as `VectorCompute` - the `VectorCompute` metadata (`VCFunction` /`VCGlobalVariable`) does. `IsVectorComputeModule` records the presence of that metadata before type translation. `VectorCompute` modules keep using `VectorAnyINTEL`, restoring the pre-KhronosGroup#3777 behavior; all other modules still prefer the multi-vendor `LongVectorEXT` when its extension is enabled.

vmaksimo reviewed Jun 10, 2026

View reviewed changes

Comment thread lib/SPIRV/SPIRVWriter.cpp Outdated

Qi-Ye-079 added 2 commits June 23, 2026 12:09

Use SPV_EXT_long_vector extension for vector size=1

4958532

Prioritize SPV_EXT_long_vector over SPV_INTEL_vector_compute

82d13de

Qi-Ye-079 force-pushed the long_vector_ext branch from c28dc3d to 82d13de Compare June 23, 2026 20:56

Qi-Ye-079 changed the title ~~Use SPV_EXT_long_vector extension for vector size=1~~ Use SPV_EXT_long_vector extension for non-standard vector size Jun 23, 2026

vmaksimo approved these changes Jun 24, 2026

View reviewed changes

vmaksimo requested review from MrSidims and svenvh June 24, 2026 10:27

MrSidims reviewed Jun 24, 2026

View reviewed changes

Add new arbitrary size for each test

d39f974

vmaksimo approved these changes Jun 26, 2026

View reviewed changes

Qi-Ye-079 requested a review from MrSidims June 26, 2026 14:48

YuriPlyakhin reviewed Jun 30, 2026

View reviewed changes

Comment thread test/extensions/EXT/SPV_EXT_long_vector/priority_over_vector_compute.ll Outdated

YuriPlyakhin reviewed Jun 30, 2026

View reviewed changes

Comment thread test/extensions/EXT/SPV_EXT_long_vector/priority_over_vector_compute.ll Outdated

YuriPlyakhin approved these changes Jun 30, 2026

View reviewed changes

Fix some nits

4f4605e

Qi-Ye-079 commented Jun 30, 2026

View reviewed changes

Comment thread test/extensions/EXT/SPV_EXT_long_vector/priority_over_vector_compute.ll Outdated

Comment thread test/extensions/EXT/SPV_EXT_long_vector/priority_over_vector_compute.ll Outdated

YuriPlyakhin approved these changes Jun 30, 2026

View reviewed changes

vmaksimo mentioned this pull request Jul 2, 2026

Keep VectorAnyINTEL for VectorCompute modules with SPV_EXT_long_vector #3829

Merged

vmaksimo requested a review from maarquitos14 July 3, 2026 09:29

maarquitos14 approved these changes Jul 7, 2026

View reviewed changes

Comment thread test/extensions/EXT/SPV_EXT_long_vector/priority_over_vector_compute_size_5.ll

YuriPlyakhin merged commit 7d4b128 into KhronosGroup:main Jul 7, 2026
9 checks passed

Uh oh!

Conversation

Qi-Ye-079 commented Jun 10, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

MrSidims commented Jun 10, 2026

Uh oh!

Qi-Ye-079 commented Jun 23, 2026

Uh oh!

vmaksimo left a comment

Choose a reason for hiding this comment

Uh oh!

MrSidims Jun 24, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Qi-Ye-079 Jun 24, 2026

Choose a reason for hiding this comment

Uh oh!

YuriPlyakhin Jun 30, 2026

Choose a reason for hiding this comment

Uh oh!

svenvh commented Jun 25, 2026

Uh oh!

Qi-Ye-079 commented Jun 25, 2026

Uh oh!

vmaksimo commented Jun 25, 2026

Uh oh!

vmaksimo left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

YuriPlyakhin left a comment

Choose a reason for hiding this comment

Uh oh!

Qi-Ye-079 commented Jun 30, 2026

Uh oh!

Qi-Ye-079 left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

vmaksimo commented Jun 30, 2026

Uh oh!

YuriPlyakhin commented Jul 7, 2026

Uh oh!

maarquitos14 left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants

Qi-Ye-079 commented Jun 10, 2026 •

edited

Loading

MrSidims Jun 24, 2026 •

edited

Loading