-
Notifications
You must be signed in to change notification settings - Fork 788
[SYCL] Change matrix type #5221
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fix pre-commit checks.
restarting the pre-commit to find out whether it's test/product issue or sporadic tool issue. |
intel/llvm-test-suite#684 and intel/llvm-test-suite#683 resolved test issue. |
// CHECK-DAG: %"struct.__spv::__spirv_JointMatrixINTEL" = | ||
// CHECK-DAG: type { [12 x [48 x [1 x [4 x i8]]]] addrspace(4)* } | ||
// CHECK-DAG: %"struct.__spv::__spirv_JointMatrixINTEL.[[#]]" = | ||
// CHECK-DAG: type { [12 x [12 x [1 x [4 x i32]]]] addrspace(4)* } | ||
// CHECK-DAG: %"struct.__spv::__spirv_JointMatrixINTEL.[[#]]" = | ||
// CHECK-DAG: type { [48 x [12 x [4 x [4 x i8]]]] addrspace(4)* } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is not the right way to handle clang-format issues.
We agreed ignore FileCheck comments, so you should update https://github.com/intel/llvm/blob/sycl/sycl/test/.clang-format to ignore CHECK-DAG:
.
26183cb
to
de3cf25
Compare
@MrSidims, please, fix linter check. |
Previously we relied on the structure type (which represented matrix type) mangling to obtain its layout. Now, when DPCPP magling scheme is aligned with C++, thus the structure lost their usual mangling. Yet we want to preserve the desired information within the matrix type, coming from DPCPP headers. To achive this the 'Matrix structure' was changed form: template <typename T, int R, int C, int L, int S> struct __spirv_JointMatrixINTEL; to template <typename T, int R, int C, int L, int S> struct __spirv_JointMatrixINTEL { T (*Value)[R][C][L + 1][S + 1]; }; so it's no longer an opaque structure and now it look like this in LLVM IR: %struct.__spirv_JointMatrixINTEL = type { [42 x [6 x [2 x [1 x i32]]]]* } Here we encode the number of Rows, Cols, Layout and Scope as sizes of an array (which element type is the same as the base matrix's type), which is a bit odd, but it's probably the best way we can preserve the information now without having the matrix type itself in LLVM. Signed-off-by: Dmitry Sidorov <dmitry.sidorov@intel.com>
Signed-off-by: Dmitry Sidorov <dmitry.sidorov@intel.com>
Signed-off-by: Dmitry Sidorov <dmitry.sidorov@intel.com>
This reverts commit 1764dac76364ad8b93b5b417950e0f81d7763923.
de3cf25
to
0b7f602
Compare
@intel/llvm-reviewers-runtime could you please take a look? |
@vladimirlaz @steffenlarsen @s-kanaev could you please take a look at PR from runtime point of view? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Unfortunate but clever w/a! Seems like the best currently possible solution.
Previously we relied on the structure type (which represented matrix
type) mangling to obtain its layout. Now, when DPCPP mangling scheme is
aligned with C++, thus the structure lost their usual mangling. Yet we
want to preserve the desired information within the matrix type, coming
from DPCPP headers. To achive this the 'Matrix structure' was changed
form:
template <typename T, int R, int C, int L, int S>
struct __spirv_JointMatrixINTEL;
to
template <typename T, int R, int C, int L, int S>
struct __spirv_JointMatrixINTEL {
T (*Value)[R][C][L + 1][S + 1];
};
so it's no longer an opaque structure and now it look like this in LLVM
IR:
%struct.__spirv_JointMatrixINTEL = type { [42 x [6 x [2 x [1 x i32]]]]* }
Here we encode the number of Rows, Cols, Layout and Scope as sizes of an
array (which element type is the same as the base matrix's type), which
is a bit odd, but it's probably the best way we can preserve the
information now without having the matrix type itself in LLVM.
Signed-off-by: Dmitry Sidorov dmitry.sidorov@intel.com