-
Notifications
You must be signed in to change notification settings - Fork 787
[SYCL] Fix integer vec conversions #11821
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
[SYCL] Fix integer vec conversions #11821
Conversation
This is a bugfix for regressions caused by intel#11770 The following cases are fixed/updated: - Signed to unsigned (and vice versa) conversions are made to always go through per-element path, because native SPIR-V instruction behavies differently from what SYCL CTS expects. Strictly speaking, this could be a CTS issue, because `vec::convert` is underspecified (see KhronosGroup/SYCL-Docs#492), but until the spec is clarified we will stick with existing behavior; - Conversions to bool are made to always go through per-element path, because under the hood bool is represented as an integer and there is no guarantee that regular integer conversion will produce the right bit patterns for `true` and `false` which are not defined by any specification; Added an on-device test to check that `vec::convert` for integer types behaves correctly and consistently on both host and device. The test uncovered that we have a problem with `std::byte` and `vec::convert`, but it seems like we have never tested a case like this and it may not be even a regression. In any case it will be fixed in a separate PR.
@intel/sycl-language-enabling-triage: FYI |
sycl/include/sycl/types.hpp
Outdated
// Whole vector conversion can only be done, if: | ||
constexpr bool canUseNativeVectorConvert = | ||
#ifdef __NVPTX__ | ||
// - we are on CUDA, see intel/llvm#11840 |
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.
Should this comment say we are not on CUDA, see intel/llvm#11840
?
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 understand the comment as "We are running on CUDA, see #11840 to understand why this is directly false.". Anyway, if it can lead to misunderstanding, we could clarify the comment to make sure it's understood by everyone in the same way.
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.
It should indeed contain not
, because this line is a continuation of a previous statement, i.e. it should be read as:
Whole vector conversion can only be done, if:
- we are not on CUDA
- other conditions required for whole vector conversions
Added "not" in as part of merge commit (311ba07)
…integer-vec-conversions This commit also fixes conversions to/from `std::byte`
|
||
if constexpr (std::is_same_v<convertT, bool>) { |
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.
@frasercrmck, FYI, this PR re-implements your fix
…integer-vec-conversions
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.
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!
This is a bugfix for regressions caused by #11770
The following cases are fixed/updated:
vec::convert
is underspecified (seevec::convert
is underspecified KhronosGroup/SYCL-Docs#492), but until the spec is clarified we will stick with existing behavior;true
andfalse
which are not defined by any specification;Added an on-device test to check that
vec::convert
for integer types behaves correctly and consistently on both host and device. The test uncovered that we have a problem withstd::byte
andvec::convert
, but it seems like we have never tested a case like this and it may not be even a regression. In any case it will be fixed in a separate PR.