[LLVM->SPIRV] Cast the GEP base pointer to source type upon mismatch

[karolzwolak]

The source element type used in a GEP may differ from the actual type of the pointer operand (e.g., ptr i8 vs. ptr [N x T]).
This mismatch can lead to incorrect address computations during translation to SPIR-V of GEP used in constexpr context, which requires that pointer types match the type of the object being accessed.

This patch inserts an explicit bitcast to convert the GEP pointer operand to the expected type, derived from the GEP’s source element type, before emitting an PtrAccessChain.
This ensures the resulting SPIR-V instruction has a correctly typed base pointer and produces valid indexing behavior.

For example:
Before this change, the following GEP was translated incorrectly:
getelementptr(i8, ptr addrspace(1) @a_var, i64 2)
Whereas this nearly equivalent GEP was handled correctly:
getelementptr inbounds ([2 x i8], ptr @a_var, i64 0, i64 1)

Previously, the first form was incorrectly interpreted as:
getelementptr inbounds ([2 x i8], ptr @a_var, i64 0, i64 2)

[karolzwolak]

@MrSidims Could you please take a look at this?
PS: I made this for previous LLVM versions, and I'm not sure what should be done on the SPIR-V untyped pointers.
Should we just skip the bitcast or is this fine?

[MrSidims]

@karolzwolak if you don't mind, I have changed the description from
This mismatch can lead to incorrect address computations during translation to SPIR-V
to
This mismatch can lead to incorrect address computations during translation to SPIR-V of GEP used in constexpr context

[MrSidims]

what should be done on the SPIR-V untyped pointers

If you are asking about SPV_KHR_untyped_pointers - I believe we can skip this corner case for now.

[karolzwolak]

Great, I don't mind the description change.