-
Notifications
You must be signed in to change notification settings - Fork 744
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
[SYCL] Initial changes for C++11 ABI=0 support #12193
Conversation
This PR attempts to support the usage case where the user sets _GLIBCXX_USE_CXX11_ABI=0 to use pre-C++11 ABI. In fact, this PR makes SCYL C++11-ABI neutral so it does not matter whether the user wants pre-C++11_ABI=0 or =1. Signed-off-by: Byoungro So <[email protected]>
Signed-off-by: Byoungro So <[email protected]>
Signed-off-by: Byoungro So <[email protected]>
Signed-off-by: Byoungro So <[email protected]>
Signed-off-by: Byoungro So <[email protected]>
Signed-off-by: Byoungro So <[email protected]>
Signed-off-by: Byoungro So <[email protected]>
Signed-off-by: Byoungro So <[email protected]>
@intel/llvm-reviewers-runtime @gmlueck @bader By the way, it seems I have to put some guard |
Signed-off-by: Byoungro So <[email protected]>
✅ With the latest revision this PR passed the C/C++ code formatter. |
Signed-off-by: Byoungro So <[email protected]>
Signed-off-by: Byoungro So <[email protected]>
Signed-off-by: Byoungro So <[email protected]>
@@ -3307,7 +3322,7 @@ class __SYCL_EXPORT handler { | |||
std::vector<detail::ArgDesc> MAssociatedAccesors; | |||
/// Struct that encodes global size, local size, ... | |||
detail::NDRDescT MNDRDesc; | |||
std::string MKernelName; | |||
detail::string MKernelName; |
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.
Every use of this seems to expect an std::string
. Do we really need to change this data member, or maybe just a few places where it's getting assigned to?
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, this private data member should cross the ABI boundary.
So I had to convert it to detail::string to overcome the ABI incompatibility issue.
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.
Oh, that brings another question. How are you testing that there are no std::string
s crossing the boundary?
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.
Also, have you tried changing callees accepting MKernelName
instead of modifying the callers?
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 can't check everywhere at this moment.
That's why this PR is only the initial changes as the title of PR says.
We will fix as we encounter from the customer's usage case.
Also, have you tried changing callees accepting MKernelName instead of modifying the callers?
I am not sure if I understand this question correctly, so please correct me if I misunderstood you.
MKernelName is defined in the headerfile, and the callees (cpp files) need this data member.
So, they accept MKernelName, but I can't hand over std::string since it is crossing the ABI boundary.
So, I changed MKernelName to detail::string and then the callee re-construct std::string in the CPP file.
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.
Do they really need std::string
? Can they keep using detail::string
or detail::string_view
?
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.
Well.. That's called code pollution.
We (including @sergey-semenov) do not want to propagate detail::string
deep on the CPP side.
detail::string
and detail::string_view
should be limited to be used when crossing the ABI boundary. They are not meant to replace std::string
and std::string_view
.
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 only partially agree with that. I think many of these interfaces currently accept const std::string &
and they have no reason to ask for that and not for std::string_view
. And if so, then everything can work automatically without us making ugly #ifdef
s: https://godbolt.org/z/Wc8Kd14Y8.
Signed-off-by: Byoungro So <[email protected]>
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.
Conditionally approving predicated on the following:
- @sergey-semenov has to approve too in order for this to be merged
- The very next PR should address
MKernelName
uses to reduce number of customizations using the strategy discussed in earlier comments and later offline. - The next PR after 2) would setup testing to ensure we don't have any other instances of
std::string
/std::string_view
on the ABI boundary. Has to come after 2) so that the approach from 2) is used here.
Co-authored-by: aelovikov-intel <[email protected]>
Co-authored-by: aelovikov-intel <[email protected]>
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 considering the plan laid out in Andrei's comment, one extra minor comment that I'm fine with being addressed in the follow up PR.
} // namespace detail | ||
|
||
/// \returns the kernel_id associated with the KernelName | ||
template <typename KernelName> kernel_id get_kernel_id() { | ||
// FIXME: This must fail at link-time if KernelName not in any available | ||
// translation units. | ||
using KI = sycl::detail::KernelInfo<KernelName>; | ||
#ifdef __INTEL_PREVIEW_BREAKING_CHANGES |
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.
You should be able to drop the else branch in favor of this one.
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.
Thanks a lot, I will address it in a follow-up PR.
This PR attempts to support the usage case where the user sets _GLIBCXX_USE_CXX11_ABI=0 to use pre-C++11 ABI.
In fact, this change addresses a specific issue with using different versions of the libstdc++ library (https://gcc.gnu.org/onlinedocs/libstdc++/manual/using_dual_abi.html has more details on this issue).
One of the major changes I made in this PR involves calling
get_info<>()
API, which can returnstdA::string
as the requested information.Due to the ABI incompatibility issues, this API internally splits into 3 cases depending on the template parameter
<T>
.<T>
s that return astd::string
.<T>
s that return astd::vector<std::string>
<T>
s that return something other than 1 or 2 above.The case 1 and 2 should return
detail::string
andstd::vector<detail::string>
instead and reconstructstd::string
s. This is required because ABIs can be different between the header and CPP files.All these 3 cases are implemented using
get_info_impl<T>
.Then, I changed the macro definition of
__SYCL_PARAM_TRAITS_SPEC
to return different types depending on the<T>
return_types.This way, we can only change the boundary between the header file and the entry point of the libsycl.