llvm

6ef0d1cc - Keep VectorAnyINTEL for VectorCompute modules with SPV_EXT_long_vector (#3829)

Keep VectorAnyINTEL for VectorCompute modules with SPV_EXT_long_vector (#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> Original commit: https://github.com/KhronosGroup/SPIRV-LLVM-Translator/commit/3238c2903cd177e