Skip to content
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

Merged
merged 115 commits into from
Mar 1, 2024
Merged

Conversation

bso-intel
Copy link
Contributor

@bso-intel bso-intel commented Dec 15, 2023

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 return stdA::string as the requested information.
Due to the ABI incompatibility issues, this API internally splits into 3 cases depending on the template parameter <T>.

  1. <T>s that return a std::string.
  2. <T>s that return a std::vector<std::string>
  3. <T>s that return something other than 1 or 2 above.

The case 1 and 2 should return detail::string and std::vector<detail::string> instead and reconstruct std::strings. 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.

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]>
@bso-intel bso-intel requested a review from a team as a code owner December 15, 2023 18:45
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]>
@bso-intel bso-intel changed the title [SYCL] Initial change for C++11 ABI=0 support [SYCL] Initial changes for C++11 ABI=0 support Dec 17, 2023
@bso-intel
Copy link
Contributor Author

@intel/llvm-reviewers-runtime @gmlueck @bader
Here is the initial PR that I presented in the DPCPP technical forum.
The intention of this PR is to get some early feedback from you.
Please do not worry about the test failures shown here since I did not change the test sources yet.

By the way, it seems I have to put some guard #ifdef __INTEL_PREVIEW_BREAKING_CHANGES because this PR breaks the ABI and we are not allowed to merge ABI-breaking changes without this guard.

sycl/include/sycl/device.hpp Outdated Show resolved Hide resolved
sycl/include/sycl/string.hpp Outdated Show resolved Hide resolved
sycl/include/sycl/string.hpp Outdated Show resolved Hide resolved
sycl/include/sycl/string.hpp Outdated Show resolved Hide resolved
Signed-off-by: Byoungro So <[email protected]>
Copy link
Contributor

github-actions bot commented Jan 4, 2024

✅ 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]>
sycl/include/sycl/device.hpp Outdated Show resolved Hide resolved
sycl/include/sycl/device.hpp Outdated Show resolved Hide resolved
sycl/include/sycl/exception.hpp Outdated Show resolved Hide resolved
sycl/include/sycl/exception.hpp Outdated Show resolved Hide resolved
@@ -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;
Copy link
Contributor

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?

Copy link
Contributor Author

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.

Copy link
Contributor

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::strings crossing the boundary?

Copy link
Contributor

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?

Copy link
Contributor Author

@bso-intel bso-intel Feb 28, 2024

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.

Copy link
Contributor

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?

Copy link
Contributor Author

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.

Copy link
Contributor

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 #ifdefs: https://godbolt.org/z/Wc8Kd14Y8.

Signed-off-by: Byoungro So <[email protected]>
Copy link
Contributor

@aelovikov-intel aelovikov-intel left a 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:

  1. @sergey-semenov has to approve too in order for this to be merged
  2. The very next PR should address MKernelName uses to reduce number of customizations using the strategy discussed in earlier comments and later offline.
  3. 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.

bso-intel and others added 2 commits February 29, 2024 11:57
Co-authored-by: aelovikov-intel <[email protected]>
Copy link
Contributor

@sergey-semenov sergey-semenov left a 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
Copy link
Contributor

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.

Copy link
Contributor Author

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.

@sergey-semenov sergey-semenov merged commit 459e122 into intel:sycl Mar 1, 2024
12 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants