SPIRV target TTI is incomplete — loop/vectorization passes use inaccurate generic costs

This is inspired by @arsenm's comment at https://github.com/llvm/llvm-project/pull/202891#issuecomment-4734684073

SPIRVTargetTransformInfo currently only implements:
- getPopcntSupport
- getFlatAddressSpace / address space intrinsic handling
- isLegalMaskedGather / isLegalMaskedScatter
- getPartialReductionCost (returns Invalid)

Everything else falls back to BasicTTIImplBase defaults, which are not meaningful for a virtual ISA like SPIR-V. This causes loop optimization passes (loop rotation, unrolling, vectorization), ReassociatePass, and SimplifyCFG transformations to make decisions
based on wrong cost estimates.

SPIR-V is an intermediate representation targeting heterogeneous backends (GPU, CPU, FPGA). Optimizations like loop unrolling and vectorization that are beneficial for concrete targets may produce worse IR for downstream compilers that will re-optimize with
accurate target knowledge.

Impact:

- SYCL SPIR-V: The downstream intel-llvm fork works around this by disabling these passes wholesale via a SYCLOptimizationMode flag when compiling for SPIR target. The root cause is that downstream SYCL still uses spir/spir64 triples, which have no LLVM backend and therefore no TTI implementation. Upstream SYCL already uses the SPIR-V target. Once the SPIR-V TTI is properly implemented with accurate cost models, the upstream SYCL SPIR-V target can run the full optimization pass pipeline without the passes making harmful decisions, and downstream SYCL can drop its pass-disabling workaround for SPIR by switching to the SPIR-V target. Tag @bader
- libclc SPIR-V: libclc currently compiles with -O0 for SPIR-V targets, forgoing all optimization. With accurate TTI, libclc could run the standard optimization pipeline to reduce code size and improve IR quality. The optimizations, guided by correct cost models, shouldn't make it more difficult to optimize later in the backend. Tag @karolherbst

The proper fix is to implement SPIR-V-appropriate (conservative or disabled) TTI responses in SPIRVTargetTransformInfo — e.g., getUnrollingPreferences, getVectorizationFactor, getArithmeticInstrCost — so passes make correct decisions without being disabled. Loop vectorizer should probably be disabled at all as it is generally not beneficial for GPU targets.

Assisted-by: Claude