[NFC][SYCL] Move ap_int to sycl::detail namespace #4822
Conversation
| @@ -325,280 +325,280 @@ __SYCL_CONVERGENT__ extern SYCL_EXTERNAL void | |||
| __spirv_SubgroupBlockWriteINTEL(__attribute__((opencl_global)) uint64_t *Ptr, | |||
| dataT Data) noexcept; | |||
| template <int W, int rW> | |||
| extern SYCL_EXTERNAL ap_int<rW> | |||
| __spirv_FixedSqrtINTEL(ap_int<W> a, bool S, int32_t I, int32_t rI, | |||
| extern SYCL_EXTERNAL __ap_int<rW> | |||
There was a problem hiding this comment.
Please do not merge without @tiwaria1 approval
There was a problem hiding this comment.
Reviewing today. Apologies for the delay.
MrSidims
force-pushed
the
private/MrSidims/ap_int
branch
from
47b5514
to
27de8f1
Compare
| int32_t Quantization = 0, int32_t Overflow = 0) noexcept; | ||
| template <int W, int rW> | ||
| extern SYCL_EXTERNAL ap_int<rW> | ||
| __spirv_FixedRecipINTEL(ap_int<W> a, bool S, int32_t I, int32_t rI, | ||
| extern SYCL_EXTERNAL __ap_int<rW> |
There was a problem hiding this comment.
Can we use sycl::detail::ap_int instead of __ap_int?
There was a problem hiding this comment.
It is not clear what is required by your toolchain.
But yes, it is better if we can just use plain names in some namespaces rather than top-level names, even if they are somehow hidden with __.
There was a problem hiding this comment.
Sure, moved to the namespace.
MrSidims
force-pushed
the
private/MrSidims/ap_int
branch
from
27de8f1
to
843fa00
Compare
MrSidims
changed the title
MrSidims
force-pushed
the
private/MrSidims/ap_int
branch
from
843fa00
to
f71f00a
Compare
|
@MrSidims, can you please address failure in Jenkins/Precommit? |
Sure, I'll take a look |
MrSidims
force-pushed
the
private/MrSidims/ap_int
branch
from
f71f00a
to
de935d9
Compare
The type isn't used directly by DPCPP programmers. Signed-off-by: Dmitry Sidorov <dmitry.sidorov@intel.com>
MrSidims
force-pushed
the
private/MrSidims/ap_int
branch
from
de935d9
to
fb2e68c
Compare
|
@tiwaria1 please take a look |
There was a problem hiding this comment.
OK, so to clarify, now ap_int is in sycl::detail::ap_int and there is no __ap_int, just the sycl::detail::ap_int? If so this looks good.
I am not sure this qualify an [NFC] tag. It breaks the API of anyone using the previous ap_int, so it is a functional change somehow.
The type isn't used directly by DPCPP programmers.
Signed-off-by: Dmitry Sidorov dmitry.sidorov@intel.com