You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
#1864 adds two new aliases for multi_ptr class: device_ptr and host_ptr that are appropriately mapped on opencl_global_device and opencl_global_host address spaces added in #1704 .
So now it's possible for users to define two functions like this: void foo(global_ptr<int>::pointer_t p) { [...] } void foo(device_ptr<int>::pointer_t p) { [...] }
For SPIR target it's okay, since the function can be overloaded due to different mangling for both of these versions. But for non-SPIR targets (for example for nvptx) the mangling will be the same, because there opencl_global_device and opencl_global_host are mapped on addressspace(1) in LLVM IR.
There are two possible solutions for this problem:
Change mangling rules;
Driver one - we can defined a macro _ENABLE_USM_ADDR_SPACES_ only for FPGA H/W and use this macro in the headers, defining __OPENCL_GLOBAL_DEVICE_AS__ as __OPENCL_GLOBAL_AS__
The text was updated successfully, but these errors were encountered:
This patch serves two purposes:
1. It reverts shift of accessors to global buffers from __global to
__global_device address space, which was considered as not a good
idea until proven otherwise. Still this shift is enabled under
-fsycl_enable_usm_address_spaces option for testing;
2. It fixes a mangling issue of functions that accepts arguments
of multi_ptr<> type for non-SPIR targets (see:
intel#2039)
Signed-off-by: Dmitry Sidorov <dmitry.sidorov@intel.com>
This patch serves two purposes:
1. It reverts shift of accessors to global buffers from __global to
__global_device address space, which was considered as not a good
idea until proven otherwise. Still this shift is enabled under
-fsycl_enable_usm_address_spaces option for testing;
2. It fixes a mangling issue of functions that accepts arguments
of multi_ptr<> type for non-SPIR targets (see:
#2039)
Signed-off-by: Dmitry Sidorov <dmitry.sidorov@intel.com>
The issue is described here: #1864 (comment)
#1864 adds two new aliases for multi_ptr class:
device_ptr
andhost_ptr
that are appropriately mapped onopencl_global_device
andopencl_global_host
address spaces added in #1704 .So now it's possible for users to define two functions like this:
void foo(global_ptr<int>::pointer_t p) { [...] } void foo(device_ptr<int>::pointer_t p) { [...] }
For SPIR target it's okay, since the function can be overloaded due to different mangling for both of these versions. But for non-SPIR targets (for example for nvptx) the mangling will be the same, because there
opencl_global_device
andopencl_global_host
are mapped onaddressspace(1)
in LLVM IR.There are two possible solutions for this problem:
_ENABLE_USM_ADDR_SPACES_
only for FPGA H/W and use this macro in the headers, defining__OPENCL_GLOBAL_DEVICE_AS__
as__OPENCL_GLOBAL_AS__
The text was updated successfully, but these errors were encountered: