Skip to content

[SYCL] Refactor cl::sycl namespace. Part1 #4397

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.

Sign up for GitHub

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

Closed
wants to merge 13 commits into from
Closed

[SYCL] Refactor cl::sycl namespace. Part1 #4397

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
13 commits
Select commit Hold shift + click to select a range
c70e525
Start namespace renaming
romanovvlad Aug 24, 2021
813b217
clang formatting
romanovvlad Aug 24, 2021
535e32e
minor Fixes
romanovvlad Aug 24, 2021
ffbead5
tiny fixes
romanovvlad Aug 24, 2021
462f4b1
Add comments and test
romanovvlad Aug 24, 2021
358994c
Apply comments and fix tests
romanovvlad Aug 30, 2021
37b945e
Merge remote-tracking branch 'public/sycl' into private2/vromanov/Alias
romanovvlad Aug 30, 2021
1fb1ec8
clang formatting
romanovvlad Aug 30, 2021
c2d6b58
more clang formatting
romanovvlad Aug 30, 2021
911d4d1
resolve comments
romanovvlad Aug 30, 2021
b24a5c0
resolve comments
romanovvlad Aug 30, 2021
24ee4ec
address comments
romanovvlad Aug 31, 2021
53d3767
Merge remote-tracking branch 'public/sycl' into private2/vromanov/Alias
romanovvlad Aug 31, 2021
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
The table of contents is too big for display.
Diff view
Diff view
  •  
  •  
  •  
14 changes: 6 additions & 8 deletions clang/lib/Sema/SemaSYCL.cpp
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -4788,8 +4788,7 @@ void SYCLIntegrationHeader::emit(raw_ostream &O) {
FwdDeclEmitter.Visit(K.NameType);
O << "\n";

O << "__SYCL_INLINE_NAMESPACE(cl) {\n";
O << "namespace sycl {\n";
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Found a problem with this change.

Copy link
Contributor

@bader bader Aug 31, 2021 •
edited
Loading

Choose a reason for hiding this comment

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

What is the problem?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

The problem is that the integration header includes defines_elementary.hpp which selects either SYCL 1.2.1 of SYCL2020 style of namespaces before we know which one should be used. So, it seems it was a bad idea to use the same macro in the integration header and for headers. Going to introduce a separate macro for integration header.

@erichkeane @premanandrao Does it sound OK?

Copy link
Contributor

Choose a reason for hiding this comment

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

That sounds like that should be alright... we just have to make sure the two stay in sync. Though, I'm not sure how you can get a macro here to work if it depends on a decision that isn't made yet. Should defines_elementary.hpp be doing all of the lifting for this set of namespaces?

Copy link
Contributor

Choose a reason for hiding this comment

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

Can we just use inline namespace cl w/o any macro defined in DPC++ headers?

Copy link
Contributor Author

@romanovvlad romanovvlad Aug 31, 2021 •
edited
Loading

Choose a reason for hiding this comment

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

That sounds like that should be alright... we just have to make sure the two stay in sync.
Though, I'm not sure how you can get a macro here to work if it depends on a decision that isn't made yet.
Should defines_elementary.hpp be doing all of the lifting for this set of namespaces?

I'm thinking about separating those namespaces. For integration header we could have a macro in the defines_elementary.hpp which, for example, defines to __sycl_int_header_ns (it's not quite suitable for the integration footer though). For headers we could you an additional header(defines_sycl_ns.hpp) which is not included from the integration header - when we include it we know which namespace version we should use.

Can we just use inline namespace cl w/o any macro defined in DPC++ headers?

We can, but we cannot use inline namespace cl, because user space will be still poluted. We can use a different namespace - __sycl_int_header_ns, but with a macro it would be easier to be in sync without FE modifications.

O << "__SYCL_OPEN_NS() {\n";
O << "namespace detail {\n";

O << "\n";
Expand Down Expand Up @@ -4868,8 +4867,8 @@ void SYCLIntegrationHeader::emit(raw_ostream &O) {
}
O << "\n";
O << "} // namespace detail\n";
O << "} // namespace sycl\n";
O << "} // __SYCL_INLINE_NAMESPACE(cl)\n";
O << "} // __SYCL_OPEN_NS()\n";
O << "__SYCL_CLOSE_NS()\n";
O << "\n";
}

Expand Down Expand Up @@ -5151,8 +5150,7 @@ bool SYCLIntegrationFooter::emit(raw_ostream &OS) {

VisitedSpecConstants.insert(VD);
std::string TopShim = EmitSpecIdShims(OS, ShimCounter, Policy, VD);
OS << "__SYCL_INLINE_NAMESPACE(cl) {\n";
OS << "namespace sycl {\n";
OS << "__SYCL_OPEN_NS() {\n";
OS << "namespace detail {\n";
OS << "template<>\n";
OS << "inline const char *get_spec_constant_symbolic_ID_impl<";
Expand All @@ -5170,8 +5168,8 @@ bool SYCLIntegrationFooter::emit(raw_ostream &OS) {
OS << "\";\n";
OS << "}\n";
OS << "} // namespace detail\n";
OS << "} // namespace sycl\n";
OS << "} // __SYCL_INLINE_NAMESPACE(cl)\n";
OS << "} // __SYCL_OPEN_NS()\n";
OS << "__SYCL_CLOSE_NS()\n";
}

if (EmittedFirstSpecConstant)
Expand Down
Loading