[SPIR-V] Stop re-writing SPIR-V type map #1047
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
There is a map used during forward translation. It links LLVM type
and SPIR-V type, that is being generated, LLVM type here is used as
a key. Due to a bug in type mapping (information is below), it's
possible that for a single pointer type in LLVM, the translator
will create 2 physically-indentical SPIR-V pointer types and with
previous implementation of mapType function the map would be changed
during the second type insertion. This patch prevents it, forcing
to reuse the type that was created first, though we would still have
an unused duplication of this type in SPIR-V module.
Please consider following LLVM IR sample:
%struct._ZTS4Args.Args = type { %struct._ZTS6Object.Object addrspace(4)* }
%struct._ZTS6Object.Object = type { i32 (%struct._ZTS6Object.Object addrspace(4)*, i32)* }
Here we have 2 LLVM type declarations. The translator will recursively
go through structure members and then through element types of the
pointer types, creating the appropriate SPIR-V types and mapping them
on LLVM types. Due to a recursive nature of this algorithm, here we will
have '%struct._ZTS6Object.Object addrspace(4)*' be processed twice with
2 SPIR-V type declaration instruction being created.
Signed-off-by: Dmitry Sidorov <[email protected]>
MrSidims
force-pushed
the
private/MrSidims/FixStoreAssertion
branch
from
f5bac25 to
dd9bb28
Compare
svenvh
reviewed
Jun 1, 2021
Signed-off-by: Dmitry Sidorov <[email protected]>
AlexeySotkin
approved these changes
Jun 2, 2021
MrSidims
added a commit
to MrSidims/SPIRV-LLVM-Translator
that referenced
this pull request
Jun 2, 2021
It's a follow up change for KhronosGroup#1047 Signed-off-by: Dmitry Sidorov <[email protected]>
MrSidims
added a commit
to MrSidims/SPIRV-LLVM-Translator
that referenced
this pull request
Jun 2, 2021
It's a follow up change for KhronosGroup#1047 Signed-off-by: Dmitry Sidorov <[email protected]>
svenvh
pushed a commit
that referenced
this pull request
Jun 7, 2021
It's a follow up change for #1047 Signed-off-by: Dmitry Sidorov <[email protected]>
svenvh
pushed a commit
to svenvh/SPIRV-LLVM-Translator
that referenced
this pull request
Jun 15, 2021
* [SPIR-V] Stop re-writing SPIR-V type map
There is a map used during forward translation. It links LLVM type
and SPIR-V type, that is being generated, LLVM type here is used as
a key. Due to a bug in type mapping (information is below), it's
possible that for a single pointer type in LLVM, the translator
will create 2 physically-indentical SPIR-V pointer types and with
previous implementation of mapType function the map would be changed
during the second type insertion. This patch prevents it, forcing
to reuse the type that was created first, though we would still have
an unused duplication of this type in SPIR-V module.
Please consider following LLVM IR sample:
%struct._ZTS4Args.Args = type { %struct._ZTS6Object.Object addrspace(4)* }
%struct._ZTS6Object.Object = type { i32 (%struct._ZTS6Object.Object addrspace(4)*, i32)* }
Here we have 2 LLVM type declarations. The translator will recursively
go through structure members and then through element types of the
pointer types, creating the appropriate SPIR-V types and mapping them
on LLVM types. Due to a recursive nature of this algorithm, here we will
have '%struct._ZTS6Object.Object addrspace(4)*' be processed twice with
2 SPIR-V type declaration instruction being created.
Signed-off-by: Dmitry Sidorov <[email protected]>
svenvh
pushed a commit
to svenvh/SPIRV-LLVM-Translator
that referenced
this pull request
Jun 15, 2021
It's a follow up change for KhronosGroup#1047 Signed-off-by: Dmitry Sidorov <[email protected]>
svenvh
pushed a commit
that referenced
this pull request
Jun 17, 2021
* [SPIR-V] Stop re-writing SPIR-V type map
There is a map used during forward translation. It links LLVM type
and SPIR-V type, that is being generated, LLVM type here is used as
a key. Due to a bug in type mapping (information is below), it's
possible that for a single pointer type in LLVM, the translator
will create 2 physically-indentical SPIR-V pointer types and with
previous implementation of mapType function the map would be changed
during the second type insertion. This patch prevents it, forcing
to reuse the type that was created first, though we would still have
an unused duplication of this type in SPIR-V module.
Please consider following LLVM IR sample:
%struct._ZTS4Args.Args = type { %struct._ZTS6Object.Object addrspace(4)* }
%struct._ZTS6Object.Object = type { i32 (%struct._ZTS6Object.Object addrspace(4)*, i32)* }
Here we have 2 LLVM type declarations. The translator will recursively
go through structure members and then through element types of the
pointer types, creating the appropriate SPIR-V types and mapping them
on LLVM types. Due to a recursive nature of this algorithm, here we will
have '%struct._ZTS6Object.Object addrspace(4)*' be processed twice with
2 SPIR-V type declaration instruction being created.
Signed-off-by: Dmitry Sidorov <[email protected]>
svenvh
pushed a commit
that referenced
this pull request
Jun 17, 2021
It's a follow up change for #1047 Signed-off-by: Dmitry Sidorov <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There is a map used during forward translation. It links LLVM type
and SPIR-V type, that is being generated, LLVM type here is used as
a key. Due to a bug in type mapping (information is below), it's
possible that for a single pointer type in LLVM, the translator
will create 2 physically-indentical SPIR-V pointer types and with
previous implementation of mapType function the map would be changed
during the second type insertion. This patch prevents it, forcing
to reuse the type that was created first, though we would still have
an unused duplication of this type in SPIR-V module.
Please consider following LLVM IR sample:
%struct._ZTS4Args.Args = type { %struct._ZTS6Object.Object addrspace(4)* }
%struct._ZTS6Object.Object = type { i32 (%struct._ZTS6Object.Object addrspace(4), i32) }
Here we have 2 LLVM type declarations. The translator will recursively
go through structure members and then through element types of the
pointer types, creating the appropriate SPIR-V types and mapping them
on LLVM types. Due to a recursive nature of this algorithm, here we will
have '%struct._ZTS6Object.Object addrspace(4)*' be processed twice with
2 SPIR-V type declaration instruction being created.
Signed-off-by: Dmitry Sidorov [email protected]