Skip to content

[Backport to 17][LLVM->SPIRV] Cast the GEP base pointer to source typ…#3612

Merged
vmaksimo merged 1 commit intoKhronosGroup:llvm_release_170from
wenju-he:17-cherry-pick-1be936678fd8bbeb224470eedbd19d78a833beb7
Mar 10, 2026
Merged

[Backport to 17][LLVM->SPIRV] Cast the GEP base pointer to source typ…#3612
vmaksimo merged 1 commit intoKhronosGroup:llvm_release_170from
wenju-he:17-cherry-pick-1be936678fd8bbeb224470eedbd19d78a833beb7

Conversation

@wenju-he
Copy link
Contributor

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

…e upon mismatch (#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)

…e upon mismatch (KhronosGroup#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

kindly ping for review

@vmaksimo vmaksimo merged commit f628677 into KhronosGroup:llvm_release_170 Mar 10, 2026
9 checks passed
@wenju-he wenju-he deleted the 17-cherry-pick-1be936678fd8bbeb224470eedbd19d78a833beb7 branch March 10, 2026 10:14
obrotowy pushed a commit to obrotowy/SPIRV-LLVM-Translator that referenced this pull request Mar 12, 2026
…e upon mismatch (KhronosGroup#3255) (KhronosGroup#3612)

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)

Co-authored-by: Karol Zwolak <karolzwolak7@gmail.com>
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