Add shorthand aliases for address spaces

[Pennycook]

Working with address spaces (e.g., when using address space casts) was previously very verbose. Defining shorthands allows long values like sycl::access::address_space::global_space to be replaced by much shorter values like sycl::global_space.

[Pennycook]

To kickstart the bikeshedding... @AerialMantis had suggested that we adopt different names here, that would be more aligned with names like memory_order_relaxed and memory_scope_group, something like address_space_global.

One way we could split the difference between sycl::global_space (19 characters) and sycl::address_space_global (27 characters) would be to define a new alias for access::address_space as well:

namespace sycl {
namespace access {
enum class address_space : int {
  global_space,
  local_space,
  private_space,
  generic_space
};
} // namespace access

using addrspace = access::address_space;
static constexpr addrspace addrspace_global = addrspace::global_space;
static constexpr addrspace addrspace_local = addrspace::local_space;
static constexpr addrspace addrspace_private = addrspace::private_space;
static constexpr addrspace addrspace_generic = addrspace::generic_space;

} // namespace sycl

...which would give us a shorthand of sycl::addrspace_global (23 characters).

Setting a precedent for use of addrspace instead of address_space might help with naming future features, too. The proposed static_address_cast and dynamic_address_cast functions could be renamed static_addrspace_cast and dynamic_addrspace_cast, maintaining the link to address spaces (and the enum) while being only 2 characters longer.

[TApplencourt]

I Agree with Gordon, I would like to keep the consistency of our mangling. I personally have no problem with address_space_global all fancy IDE will do the auto-complete (the problem was the :: IMO always painful to navigate namespace). Also we keep the 3 _ for regularity with other API as extra bonus :p

But I have no problem with addrs either.

(even if I'm still confused between Q.copy, Q.cpy, Q.memcopy, Q.memcpy and never know which one exists and the argument orders. End of my rant about alias)

[Pennycook]

(even if I'm still confused between Q.copy, Q.cpy, Q.memcopy, Q.memcpy and never know which one exists and the argument orders. End of my rant about alias)

I agree that having too many ways to do the same thing is bad. The only reason I'm suggesting to make an exception here is simply to avoid breakage between SYCL 2020 and SYCL-Next.

Between SYCL 1.2.1 and SYCL 2020 we renamed sycl::access::mode to sycl::access_mode and deprecated the old name. I think keeping the nested namespace sycl::access::address_space was a mistake, and if we'd caught this earlier we could have just had sycl::addrspace in SYCL 2020. My personal preference would still be to deprecate the old name and move everything to the new one... But I understand that this is an ABI/API concern, and so I could live with an alias. 😄

[TApplencourt]

My personal preference would still be to deprecate the old name and move everything to the new one... But I understand that this is an ABI/API concern, and so I could live with an alias

Agree! Should we deprecate it now, so we can remove it in SYCL Next?

[Pennycook]

Agree! Should we deprecate it now, so we can remove it in SYCL Next?

We should talk about this in a WG meeting.

I don't think we can deprecate things if we go the alias route. Adding [[deprecated]] to address_space would cause a deprecation warning to trigger every time somebody used addrspace (because it's only an alias).

I believe our options are:

1. Define addrspace as an alias of address_space, but keep address_space around forever for legacy code.
2. Re-define address_space as an alias of addrspace, and deprecate address_space (ABI break)
3. Define addrspace as an alias of address_space for now, planning to swap them some day far in the future.

[gmlueck]

There also a 4th option, which I'll throw out:

4. Define addrspace as a separate enumeration and add new APIs for functions that currently take address_space.

This would allow us to deprecate and eventually remove address_space and any API that uses it without incurring an ABI break.

Many of the uses of address_space are from multi_ptr, which we may decide to deprecate and replace anyways. When I noticed this, I was thinking that option (4) would be a good path forward. However, then I realized that we also use address_space extensively in atomic_ref, so option (4) seemed less ideal.

[keryell]

I am thinking to local_as, constant_as, private_as, generic_as.

as_local sounds more like a cast in LLVM/MLIR style.