Skip to content

[Backport to 19][LLVM->SPIRV] Cast the GEP base pointer to source type upon mismatch (#3255)#3615

Merged
vmaksimo merged 1 commit intoKhronosGroup:llvm_release_190from
wenju-he:19-cherry-pick-1be936678fd8bbeb224470eedbd19d78a833beb7
Mar 11, 2026
Merged

[Backport to 19][LLVM->SPIRV] Cast the GEP base pointer to source type upon mismatch (#3255)#3615
vmaksimo merged 1 commit intoKhronosGroup:llvm_release_190from
wenju-he:19-cherry-pick-1be936678fd8bbeb224470eedbd19d78a833beb7

Conversation

@wenju-he
Copy link
Contributor

@wenju-he wenju-he commented Mar 3, 2026

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)

(cherry picked from commit 1be9366)

…hronosGroup#3255)

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)

(cherry picked from commit 1be9366)
@wenju-he
Copy link
Contributor Author

wenju-he commented Mar 9, 2026

@karolzwolak please review, thanks

@vmaksimo vmaksimo merged commit 2a27c78 into KhronosGroup:llvm_release_190 Mar 11, 2026
9 checks passed
@wenju-he wenju-he deleted the 19-cherry-pick-1be936678fd8bbeb224470eedbd19d78a833beb7 branch March 11, 2026 10:48
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.

3 participants