[SYCL][Driver] Enable SPV_EXT_long_vector alongside SPV_INTEL_vector_compute

[hchilama]

Add SPV_EXT_long_vector to the default -spirv-ext= list passed to llvm-spirv, so that scalar (non-ESIMD/non-VC) SYCL modules emit size-1 vectors under the multi-vendor SPV_EXT_long_vector extension instead of SPV_INTEL_vector_compute. SPV_INTEL_vector_compute stays enabled so ESIMD / vector-compute modules keep working - when both are enabled the
SPIR-V translator picks SPV_INTEL_vector_compute for VC modules and SPV_EXT_long_vector otherwise

[sarnex]

do you know if intel gpu driver support for this extension is somewhat recent? we need to support a large range of drivers

[hchilama]

Yes, SPV_EXT_long_vector was added to IGC on 2026-07-23.

• intel/llvm CI is currently on IGC v2.38.2 per devops/dependencies.json.
• Translator producer side is ready: Use SPV_EXT_long_vector extension for non-standard vector size KhronosGroup/SPIRV-LLVM-Translator#3777 and Fixed debug info for ITT calls. #3829 are already in intel/llvm's vendored translator (llvm-spirv/), so we can emit it; only IGC-side consumption is behind.
• Backwards compat is partially preserved: when both extensions are enabled, the translator picks SPV_INTEL_vector_compute for VC/ESIMD modules and SPV_EXT_long_vector otherwise - so ESIMD/VC keeps working on all drivers; only scalar-with-size-1-vector modules would move to the new extension.

So we'd effectively be producing binaries that fail to load on every currently-shipped public Intel GPU driver for the scalar path. A few options:

1. Hold this PR until IGC uplift - wait for the next public IGC release that includes 84f80ab074+, devops/dependencies.json moves to it, then land unconditionally. Cleanest; no dead
   code paths.
2. Feature-flag off by default - add -f[no-]sycl-use-long-vector-ext, land the plumbing now, flip the default once the driver floor moves.
3. JIT-only for now - apply the change only in SPIRVLLVMTranslation.cpp and revert Clang.cpp / ClangLinkerWrapper.cpp. (Note: currently the JIT translator has no device/driver-version info at the translation call site - translatorOpts() is a process-wide singleton with no parameters. To gate it on the driver version would need a new parameter threaded from the SYCL runtime, so this option is only "safe" if it's also unconditional - meaning JIT would still produce SPV_EXT_long_vector for scalar modules and break on older drivers at JIT time.)