[clang] [clang][SYCL] Implement address space attributes for SYCL (PR #200849)

[Tom Honermann via cfe-commits]

================
@@ -873,6 +873,107 @@ expression.
   }];
 }
 
+def SYCLAddressSpaceDocs : Documentation {
+  let Category = DocCatType;
+  let Heading = "SYCL Address Spaces";
+  let Content = [{
+.. note::
+
+   These attributes are intended for use in the implementation of SYCL run-time
+   libraries and should not be used in any other context.
+   Programmers writing code intended to conform to the SYCL specification should
+   use the address space facilities specified in the following sections of the
+   SYCL 2020 specification.
+
+   * `4.7.2, "Buffers" <SYCL-2020-4.7.2_>`_
+   * `4.7.6, "Accessors" <SYCL-2020-4.7.6_>`_.
+   * `4.7.7, "Address space classes" <SYCL-2020-4.7.7_>`_.
+   * `F.7, "sycl_khr_static_addrspace_cast" <SYCL-2020-F.7_>`_.
+   * `F.8, "sycl_khr_dynamic_addrspace_cast" <SYCL-2020-F.8_>`_.
+
+The SYCL address space attributes listed below correspond to the five address
+spaces described by
+`SYCL 2020 section 3.8.2, "SYCL device memory model" <SYCL-2020-3.8.2_>`_ and
+`SYCL 2020 section 4.7.7, "Address space classes" <SYCL-2020-4.7.7_>`_.
+
+.. list-table::
+   :header-rows: 1
+
+   * - Address space attribute
+     - SYCL address space
+     - Description
+   * - ``[[clang::sycl_global]]``
+     - global
+     - A memory region accessible by all work-items executing on a device.
+   * - ``[[clang::sycl_local]]``
+     - local
+     - A memory region accessible by all work-items of a single work-group.
+   * - ``[[clang::sycl_private]]``
+     - private
+     - A memory region that is private to a single work-item.
+   * - ``[[clang::sycl_generic]]``
+     - generic
+     - A virtual memory region from which the global, local, and private memory
+       regions may all be accessed.
+   * - ``[[clang::sycl_constant]]``
+     - constant
+     - (*deprecated*) A memory region that holds constant data for an executing
+       kernel.
+
+The SYCL address space attributes are type attributes that may be applied to
+the object type of an object pointer or object reference type.
+A type specifier with a SYCL address space specifies a distinct type from the
+otherwise unattributed type.
+For example, ``int *`` and ``int [[clang::sycl_global]]*`` designate distinct
+pointer types which participate in overload resolution and template
+specialization.
+
+Conversions between SYCL address space attributed types are permitted as
+follows.
+
+* Types attributed with the global, local, or private address space attributes
+  are implicitly convertible to matching types with the generic address space
+  attribute.
+* Types attributed with the generic address space attribute may be converted
----------------
tahonermann wrote:

@elizabethandrews, I'm not following your first question. My intention is that the SYCL address space attributes are consistent with the generic address space attributes, at least with regard to appertainment. The quoted sentence is intended to communicate that, e.g., `[[clang::sycl_global]] int*` and `[[clang::sycl_global]] int&` are pointer/reference types for an object of type `int` located in the SYCL global address space.

I agree it would be useful to ensure we have a common understanding of the intended behavior. I spent quite a while investigating the behavior of the existing OpenCL address space attributes. The current behavior is inconsistent across C++, OpenCL, and SYCL language modes. I summarized my findings in a spreadsheet:
- https://docs.google.com/spreadsheets/d/12Lrwoe-t8lvS5Or3_qXh8kT5EBte5rpFTKo5UXiVW_I/edit?usp=sharing
The spreadsheet is a bit terse, so I hope it makes sense. We'll likely have to meet as you suggest to go over it; probably with @bader and perhaps others. A summary of what I found is listed towards the end along with a proposal for the conversions that I think should be permitted. My conclusions differ in a number of ways from what was proposed in the RFC you previously linked.

https://github.com/llvm/llvm-project/pull/200849