[SYCL] Specified ONEAPI aliases in functions and function objects

[maximdimakov]

Specified ONEAPI:: aliases in functions and function objects from ONEAPI namespace.
Providing the aliases for function objects is needed for intel/llvm#3868

[maximdimakov]

Not all the places with functions are here. If the changes will be allowed I'll add another

[vladimirlaz]

@maximdimakov could you please add motivation for the change? Is there any problem resolved?

[maximdimakov]

@maximdimakov could you please add motivation for the change? Is there any problem resolved?

I changed the description of PR

[vladimirlaz]

@maximdimakov could you please add motivation for the change? Is there any problem resolved?

I changed the description of PR

As soon as sub_group interface has been moved to sycl:: isn't it reasonable to update tests accordingly
@Pennycook could you please comment/approve?

[maximdimakov]

@vladimirlaz sub_group class will be moved to sycl:: but I will add aliases in ONEAPI:: so ONEAPI::sub_group will remain available.

[Pennycook]

@vladimirlaz sub_group class will be moved to sycl:: but I will add aliases in ONEAPI:: so ONEAPI::sub_group will remain available.

Are you saying that ONEAPI::sub_group will just be an alias to sycl::sub_group?

If so, I don't think that's a good idea. If I understand correctly, that would allow a developer to write something like this:

sycl::sub_group sg = it.get_sub_group(); // create a standard SYCL 2020 sub-group
auto x = sg.load(ptr); // use a member function from sycl::ONEAPI::sub_group

Would it prevent overloading a function on both sycl::ONEAPI::sub_group and sycl::sub_group? A user might want to do that.

The extension mechanism was designed to make it obvious when a user calls something that is not part of the standard -- in this case, they should create a different sub_group object in a different namespace -- and sidestepping that here seems dangerous. It also doesn't seem future-proof: we might need to change the interface for sycl::ONEAPI::sub_group or sycl::sub_group (or both), and having them reference the same class will make that more difficult.

I think my preferred solution would be to have sycl::sub_group and sycl::ONEAPI::sub_group exist as separate classes. That would still permit code re-use by moving the implementation of the classes somewhere else, and we could choose to make things easier on our users by allowing implicit conversions between the two classes. But by making them distinct classes we'd be honoring the spirit of the extension mechanism, and I think we'd avoid ADL traps like this.

Tagging @gmlueck for his opinion, since this pertains to the extension mechanism.

[gmlueck]

If the ONEAPI version of sub_group has any differences from the sycl version, then we certainly don't want to create an alias because of the problem that @Pennycook notes:

sycl::sub_group sg = it.get_sub_group(); // create a standard SYCL 2020 sub-group
auto x = sg.load(ptr); // use a member function from sycl::ONEAPI::sub_group

Even if they are exactly the same, it seems like we may not want an alias because we will want to deprecate the ONEAPI version in favor of the standard one. Therefore, it seems like defining separate types is the right thing.

[vladimirlaz]

It looks like the requested change should be applied to RT headers.
The tests are accurate (interfaces from SYCL::ONEAPI namespace are used).
@Pennycook, @AlexeySachkov could you approve the PR if no objections?

[maximdimakov]

Providing ONEAPI aliases for function objects is needed for intel/llvm#3868

[Pennycook]

I'm not opposed to rewriting the existing tests to be more explicit in their use of namespaces.