[llvm-branch-commits] [cfe-branch] r370031 - Merging r369749:
Hans Wennborg via llvm-branch-commits
llvm-branch-commits at lists.llvm.org
Tue Aug 27 02:54:32 PDT 2019
Author: hans
Date: Tue Aug 27 02:54:32 2019
New Revision: 370031
URL: http://llvm.org/viewvc/llvm-project?rev=370031&view=rev
Log:
Merging r369749:
------------------------------------------------------------------------
r369749 | stulova | 2019-08-23 13:43:49 +0200 (Fri, 23 Aug 2019) | 5 lines
[Docs][OpenCL] Several corrections to C++ for OpenCL
Differential Revision:https://reviews.llvm.org/D64418
------------------------------------------------------------------------
Modified:
cfe/branches/release_90/ (props changed)
cfe/branches/release_90/docs/LanguageExtensions.rst
cfe/branches/release_90/docs/UsersManual.rst
Propchange: cfe/branches/release_90/
------------------------------------------------------------------------------
--- svn:mergeinfo (original)
+++ svn:mergeinfo Tue Aug 27 02:54:32 2019
@@ -1,4 +1,4 @@
/cfe/branches/type-system-rewrite:134693-134817
-/cfe/trunk:366429,366447-366448,366457,366474,366480,366483,366511,366670,366694,366699,366878,367008,367039,367055,367103,367134,367301,367305,367323,367387,367403,367520,367530,367661,367675,367802,367823,367906,368104,368202,368552,368561,368874,368940,369043,369093,369251,369641,369829
+/cfe/trunk:366429,366447-366448,366457,366474,366480,366483,366511,366670,366694,366699,366878,367008,367039,367055,367103,367134,367301,367305,367323,367387,367403,367520,367530,367661,367675,367802,367823,367906,368104,368202,368552,368561,368874,368940,369043,369093,369251,369641,369749,369829
/cfe/trunk/test:170344
/cfe/trunk/test/SemaTemplate:126920
Modified: cfe/branches/release_90/docs/LanguageExtensions.rst
URL: http://llvm.org/viewvc/llvm-project/cfe/branches/release_90/docs/LanguageExtensions.rst?rev=370031&r1=370030&r2=370031&view=diff
==============================================================================
--- cfe/branches/release_90/docs/LanguageExtensions.rst (original)
+++ cfe/branches/release_90/docs/LanguageExtensions.rst Tue Aug 27 02:54:32 2019
@@ -1525,8 +1525,8 @@ OpenCL Features
C++ for OpenCL
--------------
-This functionality is built on top of OpenCL C v2.0 and C++17. Regular C++
-features can be used in OpenCL kernel code. All functionality from OpenCL C
+This functionality is built on top of OpenCL C v2.0 and C++17 enabling most of
+regular C++ features in OpenCL kernel code. Most functionality from OpenCL C
is inherited. This section describes minor differences to OpenCL C and any
limitations related to C++ support as well as interactions between OpenCL and
C++ features that are not documented elsewhere.
@@ -1537,6 +1537,7 @@ Restrictions to C++17
The following features are not supported:
- Virtual functions
+- Exceptions
- ``dynamic_cast`` operator
- Non-placement ``new``/``delete`` operators
- Standard C++ libraries. Currently there is no solution for alternative C++
@@ -1552,20 +1553,24 @@ Address space behavior
Address spaces are part of the type qualifiers; many rules are just inherited
from the qualifier behavior documented in OpenCL C v2.0 s6.5 and Embedded C
extension ISO/IEC JTC1 SC22 WG14 N1021 s3.1. Note that since the address space
-behavior in C++ is not documented formally yet, Clang extends existing concept
+behavior in C++ is not documented formally, Clang extends the existing concept
from C and OpenCL. For example conversion rules are extended from qualification
-conversion but the compatibility is determined using sets and overlapping from
-Embedded C (ISO/IEC JTC1 SC22 WG14 N1021 s3.1.3). For OpenCL it means that
-implicit conversions are allowed from named to ``__generic`` but not vice versa
-(OpenCL C v2.0 s6.5.5) except for ``__constant`` address space. Most of the
-rules are built on top of this behavior.
+conversion but the compatibility is determined using notation of sets and
+overlapping of address spaces from Embedded C (ISO/IEC JTC1 SC22 WG14 N1021
+s3.1.3). For OpenCL it means that implicit conversions are allowed from
+a named address space (except for ``__constant``) to ``__generic`` (OpenCL C
+v2.0 6.5.5). Reverse conversion is only allowed explicitly. The ``__constant``
+address space does not overlap with any other and therefore no valid conversion
+between ``__constant`` and other address spaces exists. Most of the rules
+follow this logic.
**Casts**
-C style cast will follow OpenCL C v2.0 rules (s6.5.5). All cast operators will
-permit implicit conversion to ``__generic``. However converting from named
-address spaces to ``__generic`` can only be done using ``addrspace_cast``. Note
-that conversions between ``__constant`` and any other is still disallowed.
+C-style casts follow OpenCL C v2.0 rules (s6.5.5). All cast operators
+permit conversion to ``__generic`` implicitly. However converting from
+``__generic`` to named address spaces can only be done using ``addrspace_cast``.
+Note that conversions between ``__constant`` and any other address space
+are disallowed.
.. _opencl_cpp_addrsp_deduction:
@@ -1578,7 +1583,7 @@ Address spaces are not deduced for:
- non-pointer/non-reference class members except for static data members that are
deduced to ``__global`` address space.
- non-pointer/non-reference alias declarations.
-- ``decltype`` expression.
+- ``decltype`` expressions.
.. code-block:: c++
@@ -1607,7 +1612,7 @@ TODO: Add example for type alias and dec
**References**
-References types can be qualified with an address space.
+Reference types can be qualified with an address space.
.. code-block:: c++
@@ -1622,29 +1627,29 @@ rules from address space pointer convers
**Default address space**
All non-static member functions take an implicit object parameter ``this`` that
-is a pointer type. By default this pointer parameter is in ``__generic`` address
-space. All concrete objects passed as an argument to ``this`` parameter will be
-converted to ``__generic`` address space first if the conversion is valid.
-Therefore programs using objects in ``__constant`` address space won't be compiled
-unless address space is explicitly specified using address space qualifiers on
-member functions
+is a pointer type. By default this pointer parameter is in the ``__generic``
+address space. All concrete objects passed as an argument to ``this`` parameter
+will be converted to the ``__generic`` address space first if such conversion is
+valid. Therefore programs using objects in the ``__constant`` address space will
+not be compiled unless the address space is explicitly specified using address
+space qualifiers on member functions
(see :ref:`Member function qualifier <opencl_cpp_addrspace_method_qual>`) as the
conversion between ``__constant`` and ``__generic`` is disallowed. Member function
-qualifiers can also be used in case conversion to ``__generic`` address space is
-undesirable (even if it is legal), for example to take advantage of memory bank
-accesses. Note this not only applies to regular member functions but to
-constructors and destructors too.
+qualifiers can also be used in case conversion to the ``__generic`` address space
+is undesirable (even if it is legal). For example, a method can be implemented to
+exploit memory access coalescing for segments with memory bank. This not only
+applies to regular member functions but to constructors and destructors too.
.. _opencl_cpp_addrspace_method_qual:
**Member function qualifier**
-Clang allows specifying address space qualifier on member functions to signal that
-they are to be used with objects constructed in some specific address space. This
-works just the same as qualifying member functions with ``const`` or any other
-qualifiers. The overloading resolution will select overload with most specific
-address space if multiple candidates are provided. If there is no conversion to
-to an address space among existing overloads compilation will fail with a
+Clang allows specifying an address space qualifier on member functions to signal
+that they are to be used with objects constructed in some specific address space.
+This works just the same as qualifying member functions with ``const`` or any
+other qualifiers. The overloading resolution will select the candidate with the
+most specific address space if multiple candidates are provided. If there is no
+conversion to an address space among candidates, compilation will fail with a
diagnostic.
.. code-block:: c++
@@ -1667,7 +1672,7 @@ diagnostic.
**Implicit special members**
All implicit special members (default, copy, or move constructor, copy or move
-assignment, destructor) will be generated with ``__generic`` address space.
+assignment, destructor) will be generated with the ``__generic`` address space.
.. code-block:: c++
@@ -1682,15 +1687,15 @@ assignment, destructor) will be generate
**Builtin operators**
-All builtin operators are available in the specific address spaces, thus no conversion
-to ``__generic`` is performed.
+All builtin operators are available in the specific address spaces, thus no
+conversion to ``__generic`` is performed.
**Templates**
-There is no deduction of address spaces in non-pointer/non-reference template parameters
-and dependent types (see :ref:`Deduction <opencl_cpp_addrsp_deduction>`). The address
-space of template parameter is deduced during the type deduction if it's not explicitly
-provided in instantiation.
+There is no deduction of address spaces in non-pointer/non-reference template
+parameters and dependent types (see :ref:`Deduction <opencl_cpp_addrsp_deduction>`).
+The address space of a template parameter is deduced during type deduction if
+it is not explicitly provided in the instantiation.
.. code-block:: c++
@@ -1701,13 +1706,14 @@ provided in instantiation.
5
6 __global int g;
7 void bar(){
- 8 foo(&g); // error: template instantiation failed as function scope variable appears to
- 9 // be declared in __global address space (see line 3)
+ 8 foo(&g); // error: template instantiation failed as function scope variable
+ 9 // appears to be declared in __global address space (see line 3)
10 }
-It is not legal to specify multiple different address spaces between template definition and
-instantiation. If multiple different address spaces are specified in template definition and
-instantiation compilation of such program will fail with a diagnostic.
+It is not legal to specify multiple different address spaces between template
+definition and instantiation. If multiple different address spaces are specified in
+template definition and instantiation, compilation of such a program will fail with
+a diagnostic.
.. code-block:: c++
@@ -1717,11 +1723,12 @@ instantiation compilation of such progra
}
void bar() {
- foo<__global int>(); // error: conflicting address space qualifiers are provided __global
- // and __private
+ foo<__global int>(); // error: conflicting address space qualifiers are provided
+ // __global and __private
}
-Once template is instantiated regular restrictions for address spaces will apply.
+Once a template has been instantiated, regular restrictions for address spaces will
+apply.
.. code-block:: c++
@@ -1731,15 +1738,15 @@ Once template is instantiated regular re
}
void bar(){
- foo<__global int>(); // error: function scope variable cannot be declared in __global
- // address space
+ foo<__global int>(); // error: function scope variable cannot be declared in
+ // __global address space
}
**Temporary materialization**
-All temporaries are materialized in ``__private`` address space. If a reference with some
-other address space is bound to them, the conversion will be generated in case it's valid
-otherwise compilation will fail with a diagnostic.
+All temporaries are materialized in the ``__private`` address space. If a
+reference with another address space is bound to them, the conversion will be
+generated in case it is valid, otherwise compilation will fail with a diagnostic.
.. code-block:: c++
@@ -1763,26 +1770,29 @@ TODO
Constructing and destroying global objects
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-Global objects are constructed before the first kernel using the global
+Global objects must be constructed before the first kernel using the global
objects is executed and destroyed just after the last kernel using the
program objects is executed. In OpenCL v2.0 drivers there is no specific
API for invoking global constructors. However, an easy workaround would be
-to enqueue constructor initialization kernel that has a name
+to enqueue a constructor initialization kernel that has a name
``@_GLOBAL__sub_I_<compiled file name>``. This kernel is only present if there
are any global objects to be initialized in the compiled binary. One way to
check this is by passing ``CL_PROGRAM_KERNEL_NAMES`` to ``clGetProgramInfo``
(OpenCL v2.0 s5.8.7).
-Note that if multiple files are compiled and linked into libraries multiple
+Note that if multiple files are compiled and linked into libraries, multiple
kernels that initialize global objects for multiple modules would have to be
invoked.
+Applications are currently required to run initialization of global objects
+manually before running any kernels in which the objects are used.
+
.. code-block:: console
clang -cl-std=clc++ test.cl
-If there are any global objects to be initialized the final binary will
-contain ``@_GLOBAL__sub_I_test.cl`` kernel to be enqueued.
+If there are any global objects to be initialized, the final binary will
+contain the ``@_GLOBAL__sub_I_test.cl`` kernel to be enqueued.
Global destructors can not be invoked in OpenCL v2.0 drivers. However, all
memory used for program scope objects is released on ``clReleaseProgram``.
Modified: cfe/branches/release_90/docs/UsersManual.rst
URL: http://llvm.org/viewvc/llvm-project/cfe/branches/release_90/docs/UsersManual.rst?rev=370031&r1=370030&r2=370031&view=diff
==============================================================================
--- cfe/branches/release_90/docs/UsersManual.rst (original)
+++ cfe/branches/release_90/docs/UsersManual.rst Tue Aug 27 02:54:32 2019
@@ -2397,8 +2397,8 @@ Compiling to bitcode can be done as foll
This will produce a generic test.bc file that can be used in vendor toolchains
to perform machine code generation.
-Clang currently supports OpenCL C language standards up to v2.0. Starting from Clang9
-C++ mode is available for OpenCL (see :ref:`C++ for OpenCL <opencl_cpp>`).
+Clang currently supports OpenCL C language standards up to v2.0. Starting from
+clang 9 a C++ mode is available for OpenCL (see :ref:`C++ for OpenCL <opencl_cpp>`).
OpenCL Specific Options
-----------------------
@@ -2762,21 +2762,22 @@ There are some standard OpenCL functions
C++ for OpenCL
--------------
-Starting from Clang9 kernel code can contain C++17 features: classes, templates,
+Starting from clang 9 kernel code can contain C++17 features: classes, templates,
function overloading, type deduction, etc. Please note that this is not an
implementation of `OpenCL C++
<https://www.khronos.org/registry/OpenCL/specs/2.2/pdf/OpenCL_Cxx.pdf>`_ and
there is no plan to support it in clang in any new releases in the near future.
-There are only a few restrictions on allowed C++ features. For detailed information
-please refer to documentation on Extensions (:doc:`LanguageExtensions`).
+For detailed information about restrictions to allowed C++ features please
+refer to :doc:`LanguageExtensions`.
Since C++ features are to be used on top of OpenCL C functionality, all existing
restrictions from OpenCL C v2.0 will inherently apply. All OpenCL C builtin types
-and function libraries are supported and can be used in the new mode.
+and function libraries are supported and can be used in this mode.
-To enable the new mode pass the following command line option when compiling ``.cl``
-file ``-cl-std=clc++``, ``-cl-std=CLC++``, ``-std=clc++`` or ``-std=CLC++``.
+To enable the C++ for OpenCL mode, pass one of following command line options when
+compiling ``.cl`` file ``-cl-std=clc++``, ``-cl-std=CLC++``, ``-std=clc++`` or
+``-std=CLC++``.
.. code-block:: c++
More information about the llvm-branch-commits
mailing list