-
Notifications
You must be signed in to change notification settings - Fork 130
[SYCL][Matrix] test the two features: fill a matrix and element wise operations #645
Conversation
*vector_relational test failure is unrelated and can be ignored. |
…operations Signed-off-by: Dounia Khaldi <[email protected]>
Signed-off-by: Dounia Khaldi <[email protected]>
b3723ec
to
2c66267
Compare
|
||
big_matrix<int32_t, MATRIX_M, MATRIX_N> MC((int32_t *)&C); | ||
big_matrix<int32_t, MATRIX_M, MATRIX_N> MD((int32_t *)&D); | ||
big_matrix<int8_t, MATRIX_M, MATRIX_K> MA((int8_t *)&A); |
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.
I think we should have a test with other types too, with sycl::half
for example.
} | ||
auto wi_slice_c = sub_c.get_wi_data(); | ||
for (int i = 0; i < wi_slice_c.length(); i++) { | ||
wi_slice_c[i] *= 2; |
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.
Other operations (+=, /=, <<=, %=
, .. see the full list here) and syntax (wi_slice_c[i] = wi_slice_c[i] * 2
) should be covered.
…l other operations Signed-off-by: Dounia Khaldi <[email protected]>
…ches are not merged yet Signed-off-by: Dounia Khaldi <[email protected]>
@dkhaldi is there a matching PR on intel/llvm that implements these new matrix features? |
@@ -11,6 +11,8 @@ | |||
// RUN: %CPU_RUN_PLACEHOLDER %t.out | |||
// RUN: %GPU_RUN_PLACEHOLDER %t.out | |||
|
|||
// XFAIL: * | |||
|
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.
If this is just always going to fail, is there any plan to fix or support it? If so, it would be good to mention it in a comment, otherwise someone may just remove this test.
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.
I added xfail because the test will fail until two internal patches that are currently under review get merged.
Once all the patches are in, I will remove xfail.
I just double checked with @yuxianch, the test should be marked as xfail.
But I will add a comment as you suggested
These two features have been implemented. See intel/llvm#4979 for the slicing and intel/llvm#4994 for fill. |
@cperkinsintel is SYCL :: KernelAndProgram/multiple-kernel-linking.cpp a known fail test? |
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.
LGTM
@intel/llvm-reviewers-runtime ping to merge as this needs to be cherrypicked to the internal repo as well |
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.
Thanks for the links to the PRs that introduce the new features. This LGTM.
if (wi_slice_a[i]) { | ||
if (wi_slice_a[i] > 2.0 || wi_slice_a[i] >= 2.0 || | ||
wi_slice_a[i] < 2.0 || wi_slice_a[i] <= 2.0) { | ||
T val = (wi_slice_a[i] != 2.0) ? wi_slice_a[i] : 2.0; |
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.
I think we should change the testcase according to the rules of "?: " and use static_cast for ternary operator in our code.
If the types of the second and third operands are not identical, then complex type conversion rules, as specified in the C++ Standard, are invoked. These conversions may lead to unexpected behavior including construction and destruction of temporary objects. For this reason, we strongly advise you to either (1) avoid using user-defined types as operands with the conditional operator or (2) if you do use user-defined types, then explicitly cast each operand to a common type.
if (wi_slice_a[i]) { | ||
if (wi_slice_a[i] > 2.0 || wi_slice_a[i] >= 2.0 || | ||
wi_slice_a[i] < 2.0 || wi_slice_a[i] <= 2.0) { | ||
T val = (wi_slice_a[i] != 2.0) ? wi_slice_a[i] : 2.0; |
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.
T val = (wi_slice_a[i] != 2.0) ? wi_slice_a[i] : 2.0; | |
T val = (wi_slice_a[i] != 2.0) ? wi_slice_a[i] : static_cast<half>(2.0); |
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.
@yubingex007-a11y thank you for fixing the two bugs related to fill and slicing when type deduction confusion happens, I made this change in a separate PR #727.
…operations (intel#645) Two new matrix features are being added to the DPC++ compiler namely: fill a matrix and element wise operations. This PR adds tests for these two features. Signed-off-by: Dounia Khaldi [email protected]
…operations (intel/llvm-test-suite#645) Two new matrix features are being added to the DPC++ compiler namely: fill a matrix and element wise operations. This PR adds tests for these two features. Signed-off-by: Dounia Khaldi [email protected]
Two new matrix features are being added to the DPC++ compiler namely: fill a matrix and element wise operations. This PR adds tests for these two features.
Signed-off-by: Dounia Khaldi [email protected]