Skip to content

[SYCL] Import/preprocess boost/mp11 at build time to use in SYCL headers. #5791

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

Merged
merged 13 commits into from
Mar 19, 2022

Conversation

kbobrovs
Copy link
Contributor

@kbobrovs kbobrovs commented Mar 11, 2022

Preprocessing adapts boost/mp11 headers for use in SYCL headers in a way
that does not conflict with potential use of boost in user code.
Particularly, BOOST_* macros are replaced with SYCL_BOOST_*, APIs
are moved into the top-level sycl::detail namespace. For example,
sycl::detail::boost::mp11::mp_list.

Signed-off-by: Konstantin S Bobrovsky [email protected]

…ers.

Preprocessing adapts boost/mp11 headers for use in SYCL headers in a way
that does not conflict with potential use of boost in user code.
Particularly, `BOOST_*` macros are replaced with `SYCL_BOOST_*`, APIs
are moved into the top-level `sycl` namespace. For example,
`sycl::boost::mp11::mp_list`.

Signed-off-by: Konstantin S Bobrovsky <[email protected]>
@gmlueck
Copy link
Contributor

gmlueck commented Mar 11, 2022

One thing that needs updating for sure is the sycl::boost namespace. Please suggest variants.

We should not pollute the ::sycl namespace. Implementation details go in ::sycl::detail, so maybe ::sycl::detail::boost.

@kbobrovs
Copy link
Contributor Author

One thing that needs updating for sure is the sycl::boost namespace. Please suggest variants.

We should not pollute the ::sycl namespace. Implementation details go in ::sycl::detail, so maybe ::sycl::detail::boost.

Right, we should not. @rolandschulz also suggested ::sycl::detail::boost - I will make the change.

Signed-off-by: Konstantin S Bobrovsky <[email protected]>
Signed-off-by: Konstantin S Bobrovsky <[email protected]>
Signed-off-by: Konstantin S Bobrovsky <[email protected]>
@kbobrovs kbobrovs force-pushed the import_boost_mp11 branch from 1124ea5 to e0c97c6 Compare March 12, 2022 05:24
Signed-off-by: Konstantin S Bobrovsky <[email protected]>
rolandschulz
rolandschulz previously approved these changes Mar 14, 2022
- Avoid FetchContent_MakeAvailable, as we just want to download sources,
  and not to import mp11's cmake files into build.
- Fix dependencies to make sure mp11 preprocessed headers are produced
  when making higher-level targets

Signed-off-by: Konstantin S Bobrovsky <[email protected]>
Copy link
Contributor

@pvchupin pvchupin left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@alexbatashev, can you also review this please? I'm sure you'll have some good suggestions.

@@ -126,6 +126,68 @@ install(DIRECTORY ${OpenCL_INCLUDE_DIR}/CL
DESTINATION ${SYCL_INCLUDE_DIR}/sycl
COMPONENT OpenCL-Headers)

# -------------- boost/mp11 headers import and preprocessing
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

sycl/CMakeLists.txt keeps growing, I would suggest to isolate external projects elsewhere. Maybe we should do something similar to opencl deps, basically have mp11 directory on top level with CMakeLists.txt alone and have add_llvm_external_project(mp11) here (see line 112)?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good point. I refactored the code. But I can't really add it as llvm project, as we talked, so I put mp11 modules into sycl/cmake/modules, leaving only include(<main_mp11_module_name>) in the sycl CMakeLists.txt.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

also I fixed errors arising with cmake 3.16 used in CI

Copy link
Contributor

@keryell keryell left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice, we can use Boost in the implementation? :-)
Just curious, why do you need MP11?

OUT ${OUT}
SRC_PATH ${SRC_PATH}
SRC_ID ${SRC_ID}
)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

EOL

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, fixed

@kbobrovs
Copy link
Contributor Author

Nice, we can use Boost in the implementation? :-)
Just curious, why do you need MP11?

Sort of. We can only boost::mp11 in our implementation for now :)
This is needed for invoke_simd and property_lists @steffenlarsen works on.

@kbobrovs
Copy link
Contributor Author

@pvchupin, @keryell, @gmlueck - please review, comments addressed.

@intel/llvm-reviewers-runtime, ping

@bader bader dismissed stale reviews from keryell and pvchupin via 90d1dbf March 17, 2022 10:44
@kbobrovs kbobrovs requested a review from pvchupin March 17, 2022 15:54
pvchupin
pvchupin previously approved these changes Mar 17, 2022
@pvchupin
Copy link
Contributor

ping @alexbatashev

gmlueck
gmlueck previously approved these changes Mar 17, 2022
Copy link
Contributor

@gmlueck gmlueck left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The header file path <sycl/detail/boost/mp11.hpp> and the namespace sycl::detail::boost::mp11 both look OK tome.

v-klochkov
v-klochkov previously approved these changes Mar 17, 2022
Copy link
Contributor

@v-klochkov v-klochkov left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me.
I advice to ask for one more reviewer to look at these CMake change.

alexbatashev
alexbatashev previously approved these changes Mar 18, 2022
bader
bader previously approved these changes Mar 18, 2022
@kbobrovs
Copy link
Contributor Author

Fixed comment according to review comments in [7cacacb].
@bader, @alexbatashev, @v-klochkov, @gmlueck, @pvchupin - please re-approve.

Copy link
Contributor

@bader bader left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed comment according to review comments in [7cacacb]. @bader, @alexbatashev, @v-klochkov, @gmlueck, @pvchupin - please re-approve.

I think this typo fix won't change the status and we can consider this PR approved by all these folks. Are you still waiting for reviews from @sergey-semenov, @steffenlarsen and @rolandschulz?

@kbobrovs
Copy link
Contributor Author

I think this typo fix won't change the status and we can consider this PR approved by all these folks. Are you still waiting for reviews from @sergey-semenov, @steffenlarsen and @rolandschulz?

No, I think I have enough reviews at this point.

@kbobrovs kbobrovs merged commit cae91b2 into intel:sycl Mar 19, 2022
@kbobrovs
Copy link
Contributor Author

@steffenlarsen, FYI - you can now use mp11

@kbobrovs kbobrovs deleted the import_boost_mp11 branch May 4, 2022 17:47
steffenlarsen pushed a commit that referenced this pull request Feb 10, 2023
Currently, compile-time properties are sorted using a hand-written
implementation of merge-sort. However, this PR propose to sort
compile-time properties using Boost's MP11 metaprogramming library
instead. Mp11's sorting functionality is more optimized and it also
improves the overall code readability (83 LOC vs just 11 LOC).

PS:- This PR does not introduce any new dependency as Mp11 is already
integrated into the code base (See
[#5791](#5791)).
steffenlarsen pushed a commit that referenced this pull request Feb 28, 2023
This PR reintroduces #8168 that was reverted by #8325 due to some build
errors with MSVC compilers. Upon inspection, it was found that the build
errors occur only in the case of incremental builds. With clean builds -
i.e. completely removing the build directory and
re-configuring/re-building again - there won't be any errors.

--------------
Currently, compile-time properties are sorted using a hand-written
implementation of merge-sort. However, this PR propose to sort
compile-time properties using Boost's MP11 metaprogramming library
instead. Mp11's sorting functionality is more optimized and it also
improves the overall code readability (83 LOC vs just 11 LOC).

PS:- This PR does not introduce any new dependency as Mp11 is already
integrated into the code base (See
#5791).
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.

8 participants