Reverse translation of access + load/store operations for cooperative matrix#2165
Merged
MrSidims merged 2 commits intoKhronosGroup:mainfrom Oct 4, 2023
Merged
Conversation
vmaksimo
changed the title
Contributor
Author
Contributor
|
Same comment about justification, GEP not only can't work with target ext types, but also make a little sense in terms of accessing an element of a slice of a matrix owned by the current WI - which is purely implementation defined thing. |
MrSidims
approved these changes
Sep 28, 2023
MrSidims
changed the title
vmaksimo
added a commit
to vmaksimo/SPIRV-LLVM-Translator
that referenced
this pull request
Oct 4, 2023
… matrix (KhronosGroup#2165) Implement translation via SPIR-V friendly calls, as: the LLVM instructions are not capable to accept target extension types; cooperative matrix is an opaque object and accessing elements is implementation defined, hence we can't use GEP to which AccessChain naturally maps, since GEP has a different meaning. As for now some BE would need to recognize and define what to do with a call to __spirv_AccessChain(matrix, index). Better option is to map such SPIR-V to an intrinsic or define an appropriate type in LLVM (hence defining rules for GEP and other instructions) , but it's off the table now.
MrSidims
pushed a commit
that referenced
this pull request
Oct 9, 2023
… matrix (#2165) Implement translation via SPIR-V friendly calls, as: the LLVM instructions are not capable to accept target extension types; cooperative matrix is an opaque object and accessing elements is implementation defined, hence we can't use GEP to which AccessChain naturally maps, since GEP has a different meaning. As for now some BE would need to recognize and define what to do with a call to __spirv_AccessChain(matrix, index). Better option is to map such SPIR-V to an intrinsic or define an appropriate type in LLVM (hence defining rules for GEP and other instructions) , but it's off the table now.
MrSidims
pushed a commit
to MrSidims/SPIRV-LLVM-Translator
that referenced
this pull request
Mar 25, 2025
…s for cooperative matrix (KhronosGroup#2165) Implement translation via SPIR-V friendly calls, as: the LLVM instructions are not capable to accept target extension types; cooperative matrix is an opaque object and accessing elements is implementation defined, hence we can't use GEP to which AccessChain naturally maps, since GEP has a different meaning. As for now some BE would need to recognize and define what to do with a call to __spirv_AccessChain(matrix, index). Better option is to map such SPIR-V to an intrinsic or define an appropriate type in LLVM (hence defining rules for GEP and other instructions) , but it's off the table now.
MrSidims
pushed a commit
to MrSidims/SPIRV-LLVM-Translator
that referenced
this pull request
Mar 25, 2025
…s for cooperative matrix (KhronosGroup#2165) Implement translation via SPIR-V friendly calls, as: the LLVM instructions are not capable to accept target extension types; cooperative matrix is an opaque object and accessing elements is implementation defined, hence we can't use GEP to which AccessChain naturally maps, since GEP has a different meaning. As for now some BE would need to recognize and define what to do with a call to __spirv_AccessChain(matrix, index). Better option is to map such SPIR-V to an intrinsic or define an appropriate type in LLVM (hence defining rules for GEP and other instructions) , but it's off the table now.
MrSidims
pushed a commit
to MrSidims/SPIRV-LLVM-Translator
that referenced
this pull request
Mar 25, 2025
…s for cooperative matrix (KhronosGroup#2165) Implement translation via SPIR-V friendly calls, as: the LLVM instructions are not capable to accept target extension types; cooperative matrix is an opaque object and accessing elements is implementation defined, hence we can't use GEP to which AccessChain naturally maps, since GEP has a different meaning. As for now some BE would need to recognize and define what to do with a call to __spirv_AccessChain(matrix, index). Better option is to map such SPIR-V to an intrinsic or define an appropriate type in LLVM (hence defining rules for GEP and other instructions) , but it's off the table now. Signed-off-by: Sidorov, Dmitry <dmitry.sidorov@intel.com>
MrSidims
pushed a commit
to MrSidims/SPIRV-LLVM-Translator
that referenced
this pull request
Mar 25, 2025
…s for cooperative matrix (KhronosGroup#2165) Implement translation via SPIR-V friendly calls, as: the LLVM instructions are not capable to accept target extension types; cooperative matrix is an opaque object and accessing elements is implementation defined, hence we can't use GEP to which AccessChain naturally maps, since GEP has a different meaning. As for now some BE would need to recognize and define what to do with a call to __spirv_AccessChain(matrix, index). Better option is to map such SPIR-V to an intrinsic or define an appropriate type in LLVM (hence defining rules for GEP and other instructions) , but it's off the table now.
MrSidims
pushed a commit
to MrSidims/SPIRV-LLVM-Translator
that referenced
this pull request
Mar 25, 2025
…s for cooperative matrix (KhronosGroup#2165) Implement translation via SPIR-V friendly calls, as: the LLVM instructions are not capable to accept target extension types; cooperative matrix is an opaque object and accessing elements is implementation defined, hence we can't use GEP to which AccessChain naturally maps, since GEP has a different meaning. As for now some BE would need to recognize and define what to do with a call to __spirv_AccessChain(matrix, index). Better option is to map such SPIR-V to an intrinsic or define an appropriate type in LLVM (hence defining rules for GEP and other instructions) , but it's off the table now.
MrSidims
pushed a commit
that referenced
this pull request
Mar 28, 2025
…s for cooperative matrix (#2165) Implement translation via SPIR-V friendly calls, as: the LLVM instructions are not capable to accept target extension types; cooperative matrix is an opaque object and accessing elements is implementation defined, hence we can't use GEP to which AccessChain naturally maps, since GEP has a different meaning. As for now some BE would need to recognize and define what to do with a call to __spirv_AccessChain(matrix, index). Better option is to map such SPIR-V to an intrinsic or define an appropriate type in LLVM (hence defining rules for GEP and other instructions) , but it's off the table now.
MrSidims
pushed a commit
to MrSidims/SPIRV-LLVM-Translator
that referenced
this pull request
Mar 31, 2025
…s for cooperative matrix (KhronosGroup#2165) Implement translation via SPIR-V friendly calls, as: the LLVM instructions are not capable to accept target extension types; cooperative matrix is an opaque object and accessing elements is implementation defined, hence we can't use GEP to which AccessChain naturally maps, since GEP has a different meaning. As for now some BE would need to recognize and define what to do with a call to __spirv_AccessChain(matrix, index). Better option is to map such SPIR-V to an intrinsic or define an appropriate type in LLVM (hence defining rules for GEP and other instructions) , but it's off the table now.
MrSidims
pushed a commit
to MrSidims/SPIRV-LLVM-Translator
that referenced
this pull request
May 11, 2025
…s for cooperative matrix (KhronosGroup#2165) Implement translation via SPIR-V friendly calls, as: the LLVM instructions are not capable to accept target extension types; cooperative matrix is an opaque object and accessing elements is implementation defined, hence we can't use GEP to which AccessChain naturally maps, since GEP has a different meaning. As for now some BE would need to recognize and define what to do with a call to __spirv_AccessChain(matrix, index). Better option is to map such SPIR-V to an intrinsic or define an appropriate type in LLVM (hence defining rules for GEP and other instructions) , but it's off the table now. Signed-off-by: Sidorov, Dmitry <dmitry.sidorov@intel.com>
MrSidims
pushed a commit
to MrSidims/SPIRV-LLVM-Translator
that referenced
this pull request
Aug 6, 2025
…s for cooperative matrix (KhronosGroup#2165) Implement translation via SPIR-V friendly calls, as: the LLVM instructions are not capable to accept target extension types; cooperative matrix is an opaque object and accessing elements is implementation defined, hence we can't use GEP to which AccessChain naturally maps, since GEP has a different meaning. As for now some BE would need to recognize and define what to do with a call to __spirv_AccessChain(matrix, index). Better option is to map such SPIR-V to an intrinsic or define an appropriate type in LLVM (hence defining rules for GEP and other instructions) , but it's off the table now. Signed-off-by: Sidorov, Dmitry <dmitry.sidorov@intel.com>
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 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.
Implement translation via SPIR-V friendly calls, as:
As for now some BE would need to recognize and define what to do with a call to __spirv_AccessChain(matrix, index). Better option is to map such SPIR-V to an intrinsic or define an appropriate type in LLVM (hence defining rules for GEP and other instructions) , but it's off the table now.