Skip to content
This repository was archived by the owner on Mar 28, 2023. It is now read-only.

[SYCL] Enable shuffle tests on HIP AMD. #487

Merged
merged 1 commit into from
Oct 5, 2021
Merged

Conversation

jchlanda
Copy link

@jchlanda jchlanda commented Sep 29, 2021

Even though gfx908 and gfx906 support halfs, libspirv is currently
built with tahiti as the target CPU, which means that clang rejects
AMD built-ins using halfs, for that reason half support has to stay
disabled.

@jchlanda
Copy link
Author

Corresponding work in llvm repo: intel/llvm#4664

@Pennycook
Copy link

Half test is still xfail as neither gfx908 nor gfx906 supports it.

Sorry if this is a silly question -- is this something you could work around by forwarding to an integer shuffle, or does compilation for these platforms fail as soon as they see a half type in a kernel?

@npmiller
Copy link

Half test is still xfail as neither gfx908 nor gfx906 supports it.

Sorry if this is a silly question -- is this something you could work around by forwarding to an integer shuffle, or does compilation for these platforms fail as soon as they see a half type in a kernel?

To expand a bit on that gfx906 and gfx908 actually do support half as far as I understand it, the issue is that libspirv is currently built with tahiti as the target CPU, which means that clang rejects AMD built-ins using halfs, as tahiti doesn't support them.

This is definitely an issue we need to figure out in the libclc build, but it's broader than just the subgroup builtins here, so I'm not sure if it's worth doing a workaround just for this, I also ran into it in intel/llvm#4223 a while back.

@Pennycook
Copy link

This is definitely an issue we need to figure out in the libclc build, but it's broader than just the subgroup builtins here, so I'm not sure if it's worth doing a workaround just for this, I also ran into it in intel/llvm#4223 a while back.

Got it. Thanks for the explanation.

FWIW, this sort of thing also impacts the CUDA backend. The ability to generate floating-point atomics, for example (see intel/llvm#3276) depends on the SM architecture that libclc is being built for. A general solution for multi-versioning and/or controlling the architecture used by libclc would be useful to multiple backends.

@jchlanda
Copy link
Author

To expand a bit on that gfx906 and gfx908 actually do support half as far as I understand it, the issue is that libspirv is currently built with tahiti as the target CPU, which means that clang rejects AMD built-ins using halfs, as tahiti doesn't support them.

Thanks @npmiller for the clarification, I'll update the comments to reflect that.

Even though `gfx908` and `gfx906` support halfs, libspirv is currently
built with `tahiti` as the target CPU, which means that clang rejects
AMD built-ins using halfs, for that reason half support has to stay
disabled.
@vladimirlaz vladimirlaz merged commit 36752c9 into intel:intel Oct 5, 2021
@jchlanda jchlanda deleted the shuffle branch October 5, 2021 08:17
aelovikov-intel pushed a commit to aelovikov-intel/llvm that referenced this pull request Mar 27, 2023
Even though `gfx908` and `gfx906` support halfs, libspirv is currently
built with `tahiti` as the target CPU, which means that clang rejects
AMD built-ins using halfs, for that reason half support has to stay
disabled.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants