Skip to content

Conversation

@MrSidims
Copy link
Contributor

No description provided.

…ooperative matrixes (KhronosGroup#2166)

Implement translation via SPIR-V friendly calls, as:

the LLVM instructions are not capable to accept target extension types;
matrix arithmetic instructions require additional carry additional rules, which LLVM can not perform (for example while technically Add for vectors and (flattened) matrices is the same - yet for matrices we need to perform extra checks, also mul instruction is complitely different).
As for now some BE would need to recognize and define what to do with a call to __spirv_FMul(matrixA, matrixB). 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.
…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 MrSidims force-pushed the llvm_release_160-matrix-backports branch from 45b82ac to 033f849 Compare March 31, 2025 11:34
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.

2 participants