Editorial fix in vector section #522
Conversation
| down to a <<backend>> built-in vector types on SYCL devices, where possible, and | ||
| provides compatible support on the host or when it is not possible. | ||
| down to a <<backend>> built-in vector type on SYCL devices, where possible, and | ||
| provides compatible support on the host when not possible. |
There was a problem hiding this comment.
This entire sentence seems like an implementation detail to me. How could you write a test for this sentence? It just says that it might or might not use a built-in vector type in device code.
The part about "provides compatible support on the host when not possible" seems not quite accurate. The vec type works on the host regardless of how vec is implemented in device code. So, I think this part of the sentence is just saying that vec is also available in host code. We say that already in the first sentence of the first paragraph in this section.
I think we should just delete the sentence, rather than trying to fix it.
There was a problem hiding this comment.
Agreed. The PR should now reflect this
There was a problem hiding this comment.
Thanks. Can you update the description of this PR also?
|
It would be nice to have a couple other company reviewers on this small PR. |
|
WG approves merge |
Editorial fix in vector section
Editorial fix in vector section (cherry picked from commit 3f9aae0)
Editorial fix in vector section (cherry picked from commit 3f9aae0)
This fix makes the wording better, but I'm actually not sure what it means to have compatible support on the host when device support isn't possible. Should the later part of this sentence be dropped totally, since I don't think there is alternate host emulation? There is independently compatible support for the vector types on the host, unrelated to what the device supports, AFAICT.