-
Notifications
You must be signed in to change notification settings - Fork 787
[HIP] Add generic address space impl of __spirv_ocl_frexp for HIP backend #5377
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.
LGTM, although vector variant implementations are verbose and it would be great to re-use vector functions instead of scalar versions.
__CLC_GENTYPE_VEC res = (__CLC_GENTYPE_VEC)(__spirv_ocl_frexp(x.s0, &ep_0), | ||
__spirv_ocl_frexp(x.s1, &ep_1), | ||
__spirv_ocl_frexp(x.s2, &ep_2), | ||
__spirv_ocl_frexp(x.s3, &ep_3)); |
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.
Can't we use VEC_FUNCNAME(2)
here? Similar to the existing approach where computation for vector length 2*N done by combining results for vector length N.
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.
Yes, that is possible but would it not lead to extra vector being created? For example VEC_FUNCNAME(16) would create a 8 int2, 4 int4, 2 int8 and an int16.
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.
VEC_FUNCNAME(16) should create just 2 int8. Currently it creates 16(!) scalar values, so I don't think creating 2 int8 should be a problem.
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.
Sorry, I think I didn't get your concern right. There should be no overhead on creating vectors. Compiler should generate the same for code for both variants. It's just less code to read.
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.
Ok, looking at _CLC_V_V_VP_VECTORIZE and modf this also seems to be a fairly common pattern. Thanks!
…cos for amd backend
49cb87d
to
54e3c5e
Compare
Apologies, I accidentally rebased. It's almost all redone anyway. |
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'm not sure if I've put it in the correct place or if this needs to be added to the SOURCES file or CMake somewhere, can you please advise.
I suggest we change the file extension from .cl
to .h
for mangle_common.cl.
According to my understanding SOURCES is used to enable the library binary re-build when sources are changed, so adding new files impacting re-build results is required.
Everything else looks good.
@@ -6,81 +6,104 @@ | |||
// | |||
//===----------------------------------------------------------------------===// | |||
|
|||
#include "mangle_common.cl" |
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.
#include "mangle_common.cl" | |
#include "mangle_common.h" |
I think the problem is that |
Hi @bader, I noticed that modf, sincos and frexp dont work for the half type, but this isn't just limited to the HIP backend.
Is it ok if open an issue for this? |
Yes. Please, file a bug report. |
Bug reported here: #5418 |
This involved manually mangling the namespaces since the default would be address space 5 otherwise.