Skip to content

[Backport to 15] Use SPV_EXT_long_vector extension for non-standard vector size,Keep VectorAnyINTEL for VectorCompute modules with SPV_EXT_long_vector#3848

Open
Qi-Ye-079 wants to merge 1 commit into
KhronosGroup:llvm_release_150from
Qi-Ye-079:bp15-long-vector-ext
Open

[Backport to 15] Use SPV_EXT_long_vector extension for non-standard vector size,Keep VectorAnyINTEL for VectorCompute modules with SPV_EXT_long_vector#3848
Qi-Ye-079 wants to merge 1 commit into
KhronosGroup:llvm_release_150from
Qi-Ye-079:bp15-long-vector-ext

Conversation

@Qi-Ye-079

Copy link
Copy Markdown
Contributor

Backport of #3777, #3829

…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.
@Qi-Ye-079 Qi-Ye-079 force-pushed the bp15-long-vector-ext branch from 89f5141 to cc65edc Compare July 9, 2026 22:33
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant