[clang] [HIP] Document func ptr and virtual func (PR #68126)
https://github.com/yxsamliu closed https://github.com/llvm/llvm-project/pull/68126 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [HIP] Document func ptr and virtual func (PR #68126)
https://github.com/Artem-B approved this pull request. https://github.com/llvm/llvm-project/pull/68126 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [HIP] Document func ptr and virtual func (PR #68126)
scchan wrote: LGTM thanks https://github.com/llvm/llvm-project/pull/68126 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [HIP] Document func ptr and virtual func (PR #68126)
https://github.com/b-sumner commented: Looks good to me. https://github.com/llvm/llvm-project/pull/68126 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [HIP] Document func ptr and virtual func (PR #68126)
@@ -176,3 +176,95 @@ Predefined Macros * - ``HIP_API_PER_THREAD_DEFAULT_STREAM`` - Alias to ``__HIP_API_PER_THREAD_DEFAULT_STREAM__``. Deprecated. +Compilation Modes += + +Each HIP source file contains intertwined device and host code. Depending on the chosen compilation mode by the compiler options ``-fno-gpu-rdc`` and ``-fgpu-rdc``, these portions of code are compiled differently. + +Device Code Compilation +--- + +**``-fno-gpu-rdc`` Mode (default)**: + +- Compiles to a self-contained, fully linked offloading device binary for each offloading device architecture. +- Device code within a Translation Unit (TU) cannot call functions located in another TU. + +**``-fgpu-rdc`` Mode**: + +- Compiles to a bitcode for each GPU architecture. +- For each offloading device architecture, the bitcode from different TUs are linked together to create a single offloading device binary. +- Device code in one TU can call functions located in another TU. + +Host Code Compilation +- + +**Both Modes**: + +- Compiles to a relocatable object for each TU. +- These relocatable objects are then linked together. +- Host code within a TU can call host functions and launch kernels from another TU. + +Function Pointers Support += + +Function pointers' support varies with the usage mode in Clang with HIP. The following table provides an overview of the support status across different use-cases and modes. + +.. list-table:: Function Pointers Support Overview + :widths: 25 25 25 + :header-rows: 1 + + * - Use Case + - ``-fno-gpu-rdc`` Mode (default) + - ``-fgpu-rdc`` Mode + * - Defined and used in the same TU + - Supported + - Supported + * - Defined in one TU and used in another TU + - Not Supported + - Supported + +In the ``-fno-gpu-rdc`` mode, the compiler calculates the resource usage of kernels based only on functions present within the same TU. This mode does not support the use of function pointers defined in a different TU due to the possibility of incorrect resource usage calculations, leading to undefined behavior. + +On the other hand, the ``-fgpu-rdc`` mode allows the definition and use of function pointers across different TUs, as resource usage calculations can accommodate functions from disparate TUs. + +Virtual Function Support + + +In Clang with HIP, support for calling virtual functions of an object in device or host code is contingent on where the object is constructed. + +- **Constructed in Device Code**: Virtual functions of an object can be called in device code on a specific offloading device if the object is constructed in device code on an offloading device with the same architecture. +- **Constructed in Host Code**: Virtual functions of an object can be called in host code if the object is constructed in host code. + +In other scenarios, calling virtual functions is not allowed. + +Explanation +--- + +An object constructed on the device side contains a pointer to the virtual function table on the device side, which is not accessible in host code, and vice versa. Thus, trying to invoke virtual functions from a context different from where the object was constructed will be disallowed because the appropriate virtual table cannot be accessed. The virtual function tables for offloading devices with different architecures are different, therefore trying to invoke virtual functions from an offloading device with a different architecture than where the object is constructed is also disallowed. + +A possible way to alleviate the current limitation of virtual function support in HIP is through the use of a "composite vtable". This involves creating a vtable that combines those from the host and all offloading device architectures, storing it in memory accessible by both. A dedicated registration function is introduced to populate this composite vtable. This function is invoked during global initialization to ensure the vtable is ready before any virtual function calls are made. For every virtual function call, irrespective of context, the system refers to this composite vtable to determine the correct function execution. yxsamliu wrote: removed the paragraph https://github.com/llvm/llvm-project/pull/68126 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [HIP] Document func ptr and virtual func (PR #68126)
https://github.com/yxsamliu updated
https://github.com/llvm/llvm-project/pull/68126
>From 52fa4eac701a411699ac0ffa8386b1b23ba9977e Mon Sep 17 00:00:00 2001
From: "Yaxun (Sam) Liu"
Date: Tue, 3 Oct 2023 12:21:10 -0400
Subject: [PATCH 1/2] [HIP] Document func ptr and virtual func
Document clang support for function pointers and virtual functions with HIP
---
clang/docs/HIPSupport.rst | 62 +++
1 file changed, 62 insertions(+)
diff --git a/clang/docs/HIPSupport.rst b/clang/docs/HIPSupport.rst
index 8b4649733a9c777..63c16c0051153a0 100644
--- a/clang/docs/HIPSupport.rst
+++ b/clang/docs/HIPSupport.rst
@@ -176,3 +176,65 @@ Predefined Macros
* - ``HIP_API_PER_THREAD_DEFAULT_STREAM``
- Alias to ``__HIP_API_PER_THREAD_DEFAULT_STREAM__``. Deprecated.
+Function Pointers Support in Clang with HIP
+===
+
+Function pointers' support varies with the usage mode in Clang with HIP. The
following table provides an overview of the support status across different
use-cases and modes.
+
+.. list-table:: Function Pointers Support Overview
+ :widths: 25 25 25
+ :header-rows: 1
+
+ * - Use Case
+ - ``-fno-gpu-rdc`` Mode (default)
+ - ``-fgpu-rdc`` Mode
+ * - Defined and used in the same TU
+ - Supported
+ - Supported
+ * - Defined in one TU and used in another TU
+ - Not Supported
+ - Supported
+
+In the ``-fno-gpu-rdc`` mode, the compiler calculates the resource usage of
kernels based only on functions present within the same Translation Unit (TU).
This mode does not support the use of function pointers defined in a different
TU due to the possibility of incorrect resource usage calculations, leading to
undefined behavior.
+
+On the other hand, the ``-fgpu-rdc`` mode allows the definition and use of
function pointers across different TUs, as resource usage calculations can
accommodate functions from disparate TUs.
+
+Virtual Function Support in Clang with HIP
+==
+
+In Clang with HIP, support for calling virtual functions of an object in
device or host code is contingent on where the object is constructed.
+
+- **Constructed in Device Code**: Virtual functions of an object can be called
in device code if the object is constructed in device code.
+- **Constructed in Host Code**: Virtual functions of an object can be called
in host code if the object is constructed in host code.
+
+In other scenarios, calling virtual functions is not allowed.
+
+Explanation
+---
+
+An object constructed on the device side contains a pointer to the virtual
function table on the device side, which is not accessible in host code, and
vice versa. Thus, trying to invoke virtual functions from a context different
from where the object was constructed will be disallowed because the
appropriate virtual table cannot be accessed.
+
+Example Usage
+-
+
+.. code-block:: c++
+
+ class Base {
+ public:
+ __device__ virtual void virtualFunction() {
+ // Base virtual function implementation
+ }
+ };
+
+ class Derived : public Base {
+ public:
+ __device__ void virtualFunction() override {
+ // Derived virtual function implementation
+ }
+ };
+
+ __global__ void kernel() {
+ Derived obj;
+ Base* basePtr =
+ basePtr->virtualFunction(); // Allowed since obj is constructed in
device code
+ }
>From 60c7fd700a22f22b5d89c3a9086a1962e1827c41 Mon Sep 17 00:00:00 2001
From: "Yaxun (Sam) Liu"
Date: Sat, 7 Oct 2023 10:37:54 -0400
Subject: [PATCH 2/2] [HIP] Document func ptr and virtual func
Document clang support for function pointers and virtual functions with HIP
---
clang/docs/HIPSupport.rst | 42 ---
1 file changed, 35 insertions(+), 7 deletions(-)
diff --git a/clang/docs/HIPSupport.rst b/clang/docs/HIPSupport.rst
index 63c16c0051153a0..84cee45e83ba3c8 100644
--- a/clang/docs/HIPSupport.rst
+++ b/clang/docs/HIPSupport.rst
@@ -176,8 +176,36 @@ Predefined Macros
* - ``HIP_API_PER_THREAD_DEFAULT_STREAM``
- Alias to ``__HIP_API_PER_THREAD_DEFAULT_STREAM__``. Deprecated.
-Function Pointers Support in Clang with HIP
-===
+Compilation Modes
+=
+
+Each HIP source file contains intertwined device and host code. Depending on
the chosen compilation mode by the compiler options ``-fno-gpu-rdc`` and
``-fgpu-rdc``, these portions of code are compiled differently.
+
+Device Code Compilation
+---
+
+**``-fno-gpu-rdc`` Mode (default)**:
+
+- Compiles to a self-contained, fully linked offloading device binary for each
offloading device architecture.
+- Device code within a Translation Unit (TU) cannot call functions located in
another TU.
+
+**``-fgpu-rdc`` Mode**:
+
+- Compiles to a bitcode for each GPU architecture.
+- For each offloading device architecture, the bitcode from different
[clang] [HIP] Document func ptr and virtual func (PR #68126)
@@ -176,3 +176,95 @@ Predefined Macros * - ``HIP_API_PER_THREAD_DEFAULT_STREAM`` - Alias to ``__HIP_API_PER_THREAD_DEFAULT_STREAM__``. Deprecated. +Compilation Modes += + +Each HIP source file contains intertwined device and host code. Depending on the chosen compilation mode by the compiler options ``-fno-gpu-rdc`` and ``-fgpu-rdc``, these portions of code are compiled differently. + +Device Code Compilation +--- + +**``-fno-gpu-rdc`` Mode (default)**: + +- Compiles to a self-contained, fully linked offloading device binary for each offloading device architecture. +- Device code within a Translation Unit (TU) cannot call functions located in another TU. + +**``-fgpu-rdc`` Mode**: + +- Compiles to a bitcode for each GPU architecture. +- For each offloading device architecture, the bitcode from different TUs are linked together to create a single offloading device binary. +- Device code in one TU can call functions located in another TU. + +Host Code Compilation +- + +**Both Modes**: + +- Compiles to a relocatable object for each TU. +- These relocatable objects are then linked together. +- Host code within a TU can call host functions and launch kernels from another TU. + +Function Pointers Support += + +Function pointers' support varies with the usage mode in Clang with HIP. The following table provides an overview of the support status across different use-cases and modes. + +.. list-table:: Function Pointers Support Overview + :widths: 25 25 25 + :header-rows: 1 + + * - Use Case + - ``-fno-gpu-rdc`` Mode (default) + - ``-fgpu-rdc`` Mode + * - Defined and used in the same TU + - Supported + - Supported + * - Defined in one TU and used in another TU + - Not Supported + - Supported + +In the ``-fno-gpu-rdc`` mode, the compiler calculates the resource usage of kernels based only on functions present within the same TU. This mode does not support the use of function pointers defined in a different TU due to the possibility of incorrect resource usage calculations, leading to undefined behavior. + +On the other hand, the ``-fgpu-rdc`` mode allows the definition and use of function pointers across different TUs, as resource usage calculations can accommodate functions from disparate TUs. + +Virtual Function Support + + +In Clang with HIP, support for calling virtual functions of an object in device or host code is contingent on where the object is constructed. + +- **Constructed in Device Code**: Virtual functions of an object can be called in device code on a specific offloading device if the object is constructed in device code on an offloading device with the same architecture. +- **Constructed in Host Code**: Virtual functions of an object can be called in host code if the object is constructed in host code. + +In other scenarios, calling virtual functions is not allowed. + +Explanation +--- + +An object constructed on the device side contains a pointer to the virtual function table on the device side, which is not accessible in host code, and vice versa. Thus, trying to invoke virtual functions from a context different from where the object was constructed will be disallowed because the appropriate virtual table cannot be accessed. The virtual function tables for offloading devices with different architecures are different, therefore trying to invoke virtual functions from an offloading device with a different architecture than where the object is constructed is also disallowed. + +A possible way to alleviate the current limitation of virtual function support in HIP is through the use of a "composite vtable". This involves creating a vtable that combines those from the host and all offloading device architectures, storing it in memory accessible by both. A dedicated registration function is introduced to populate this composite vtable. This function is invoked during global initialization to ensure the vtable is ready before any virtual function calls are made. For every virtual function call, irrespective of context, the system refers to this composite vtable to determine the correct function execution. b-sumner wrote: I would avoid speculating in this documentation. Maybe we should remove this paragraph? https://github.com/llvm/llvm-project/pull/68126 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [HIP] Document func ptr and virtual func (PR #68126)
yxsamliu wrote: ping https://github.com/llvm/llvm-project/pull/68126 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [HIP] Document func ptr and virtual func (PR #68126)
@@ -176,3 +176,95 @@ Predefined Macros * - ``HIP_API_PER_THREAD_DEFAULT_STREAM`` - Alias to ``__HIP_API_PER_THREAD_DEFAULT_STREAM__``. Deprecated. +Compilation Modes += + +Each HIP source file contains intertwined device and host code. Depending on the chosen compilation mode by the compiler options ``-fno-gpu-rdc`` and ``-fgpu-rdc``, these portions of code are compiled differently. + +Device Code Compilation +--- + +**``-fno-gpu-rdc`` Mode (default)**: + +- Compiles to a self-contained, fully linked offloading device binary for each offloading device architecture. +- Device code within a Translation Unit (TU) cannot call functions located in another TU. + +**``-fgpu-rdc`` Mode**: + +- Compiles to a bitcode for each GPU architecture. +- For each offloading device architecture, the bitcode from different TUs are linked together to create a single offloading device binary. +- Device code in one TU can call functions located in another TU. + +Host Code Compilation +- + +**Both Modes**: + +- Compiles to a relocatable object for each TU. +- These relocatable objects are then linked together. +- Host code within a TU can call host functions and launch kernels from another TU. + +Function Pointers Support += + +Function pointers' support varies with the usage mode in Clang with HIP. The following table provides an overview of the support status across different use-cases and modes. + +.. list-table:: Function Pointers Support Overview + :widths: 25 25 25 + :header-rows: 1 + + * - Use Case + - ``-fno-gpu-rdc`` Mode (default) + - ``-fgpu-rdc`` Mode + * - Defined and used in the same TU + - Supported + - Supported + * - Defined in one TU and used in another TU + - Not Supported + - Supported + +In the ``-fno-gpu-rdc`` mode, the compiler calculates the resource usage of kernels based only on functions present within the same TU. This mode does not support the use of function pointers defined in a different TU due to the possibility of incorrect resource usage calculations, leading to undefined behavior. + +On the other hand, the ``-fgpu-rdc`` mode allows the definition and use of function pointers across different TUs, as resource usage calculations can accommodate functions from disparate TUs. + +Virtual Function Support + + +In Clang with HIP, support for calling virtual functions of an object in device or host code is contingent on where the object is constructed. + +- **Constructed in Device Code**: Virtual functions of an object can be called in device code on a specific offloading device if the object is constructed in device code on an offloading device with the same architecture. +- **Constructed in Host Code**: Virtual functions of an object can be called in host code if the object is constructed in host code. + +In other scenarios, calling virtual functions is not allowed. + +Explanation +--- + +An object constructed on the device side contains a pointer to the virtual function table on the device side, which is not accessible in host code, and vice versa. Thus, trying to invoke virtual functions from a context different from where the object was constructed will be disallowed because the appropriate virtual table cannot be accessed. The virtual function tables for offloading devices with different architecures are different, therefore trying to invoke virtual functions from an offloading device with a different architecture than where the object is constructed is also disallowed. + +A possible way to alleviate the current limitation of virtual function support in HIP is through the use of a "composite vtable". This involves creating a vtable that combines those from the host and all offloading device architectures, storing it in memory accessible by both. A dedicated registration function is introduced to populate this composite vtable. This function is invoked during global initialization to ensure the vtable is ready before any virtual function calls are made. For every virtual function call, irrespective of context, the system refers to this composite vtable to determine the correct function execution. yxsamliu wrote: It is a possible solution. However, there may be better solutions that I am open to discussion. https://github.com/llvm/llvm-project/pull/68126 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [HIP] Document func ptr and virtual func (PR #68126)
@@ -176,3 +176,95 @@ Predefined Macros * - ``HIP_API_PER_THREAD_DEFAULT_STREAM`` - Alias to ``__HIP_API_PER_THREAD_DEFAULT_STREAM__``. Deprecated. +Compilation Modes += + +Each HIP source file contains intertwined device and host code. Depending on the chosen compilation mode by the compiler options ``-fno-gpu-rdc`` and ``-fgpu-rdc``, these portions of code are compiled differently. + +Device Code Compilation +--- + +**``-fno-gpu-rdc`` Mode (default)**: + +- Compiles to a self-contained, fully linked offloading device binary for each offloading device architecture. +- Device code within a Translation Unit (TU) cannot call functions located in another TU. + +**``-fgpu-rdc`` Mode**: + +- Compiles to a bitcode for each GPU architecture. +- For each offloading device architecture, the bitcode from different TUs are linked together to create a single offloading device binary. +- Device code in one TU can call functions located in another TU. + +Host Code Compilation +- + +**Both Modes**: + +- Compiles to a relocatable object for each TU. +- These relocatable objects are then linked together. +- Host code within a TU can call host functions and launch kernels from another TU. + +Function Pointers Support += + +Function pointers' support varies with the usage mode in Clang with HIP. The following table provides an overview of the support status across different use-cases and modes. + +.. list-table:: Function Pointers Support Overview + :widths: 25 25 25 + :header-rows: 1 + + * - Use Case + - ``-fno-gpu-rdc`` Mode (default) + - ``-fgpu-rdc`` Mode + * - Defined and used in the same TU + - Supported + - Supported + * - Defined in one TU and used in another TU + - Not Supported + - Supported + +In the ``-fno-gpu-rdc`` mode, the compiler calculates the resource usage of kernels based only on functions present within the same TU. This mode does not support the use of function pointers defined in a different TU due to the possibility of incorrect resource usage calculations, leading to undefined behavior. + +On the other hand, the ``-fgpu-rdc`` mode allows the definition and use of function pointers across different TUs, as resource usage calculations can accommodate functions from disparate TUs. + +Virtual Function Support + + +In Clang with HIP, support for calling virtual functions of an object in device or host code is contingent on where the object is constructed. + +- **Constructed in Device Code**: Virtual functions of an object can be called in device code on a specific offloading device if the object is constructed in device code on an offloading device with the same architecture. +- **Constructed in Host Code**: Virtual functions of an object can be called in host code if the object is constructed in host code. + +In other scenarios, calling virtual functions is not allowed. + +Explanation +--- + +An object constructed on the device side contains a pointer to the virtual function table on the device side, which is not accessible in host code, and vice versa. Thus, trying to invoke virtual functions from a context different from where the object was constructed will be disallowed because the appropriate virtual table cannot be accessed. The virtual function tables for offloading devices with different architecures are different, therefore trying to invoke virtual functions from an offloading device with a different architecture than where the object is constructed is also disallowed. + +A possible way to alleviate the current limitation of virtual function support in HIP is through the use of a "composite vtable". This involves creating a vtable that combines those from the host and all offloading device architectures, storing it in memory accessible by both. A dedicated registration function is introduced to populate this composite vtable. This function is invoked during global initialization to ensure the vtable is ready before any virtual function calls are made. For every virtual function call, irrespective of context, the system refers to this composite vtable to determine the correct function execution. scchan wrote: Could you clarify whether the purpose of this pragraph is to provide a potential workaround to users or a solution in a future compiler? https://github.com/llvm/llvm-project/pull/68126 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [HIP] Document func ptr and virtual func (PR #68126)
https://github.com/yxsamliu updated
https://github.com/llvm/llvm-project/pull/68126
>From cb0a36f061ee7c31eb63655ce0ecea00e1a94dec Mon Sep 17 00:00:00 2001
From: "Yaxun (Sam) Liu"
Date: Tue, 3 Oct 2023 12:21:10 -0400
Subject: [PATCH 1/2] [HIP] Document func ptr and virtual func
Document clang support for function pointers and virtual functions with HIP
---
clang/docs/HIPSupport.rst | 62 +++
1 file changed, 62 insertions(+)
diff --git a/clang/docs/HIPSupport.rst b/clang/docs/HIPSupport.rst
index 8b4649733a9c777..63c16c0051153a0 100644
--- a/clang/docs/HIPSupport.rst
+++ b/clang/docs/HIPSupport.rst
@@ -176,3 +176,65 @@ Predefined Macros
* - ``HIP_API_PER_THREAD_DEFAULT_STREAM``
- Alias to ``__HIP_API_PER_THREAD_DEFAULT_STREAM__``. Deprecated.
+Function Pointers Support in Clang with HIP
+===
+
+Function pointers' support varies with the usage mode in Clang with HIP. The
following table provides an overview of the support status across different
use-cases and modes.
+
+.. list-table:: Function Pointers Support Overview
+ :widths: 25 25 25
+ :header-rows: 1
+
+ * - Use Case
+ - ``-fno-gpu-rdc`` Mode (default)
+ - ``-fgpu-rdc`` Mode
+ * - Defined and used in the same TU
+ - Supported
+ - Supported
+ * - Defined in one TU and used in another TU
+ - Not Supported
+ - Supported
+
+In the ``-fno-gpu-rdc`` mode, the compiler calculates the resource usage of
kernels based only on functions present within the same Translation Unit (TU).
This mode does not support the use of function pointers defined in a different
TU due to the possibility of incorrect resource usage calculations, leading to
undefined behavior.
+
+On the other hand, the ``-fgpu-rdc`` mode allows the definition and use of
function pointers across different TUs, as resource usage calculations can
accommodate functions from disparate TUs.
+
+Virtual Function Support in Clang with HIP
+==
+
+In Clang with HIP, support for calling virtual functions of an object in
device or host code is contingent on where the object is constructed.
+
+- **Constructed in Device Code**: Virtual functions of an object can be called
in device code if the object is constructed in device code.
+- **Constructed in Host Code**: Virtual functions of an object can be called
in host code if the object is constructed in host code.
+
+In other scenarios, calling virtual functions is not allowed.
+
+Explanation
+---
+
+An object constructed on the device side contains a pointer to the virtual
function table on the device side, which is not accessible in host code, and
vice versa. Thus, trying to invoke virtual functions from a context different
from where the object was constructed will be disallowed because the
appropriate virtual table cannot be accessed.
+
+Example Usage
+-
+
+.. code-block:: c++
+
+ class Base {
+ public:
+ __device__ virtual void virtualFunction() {
+ // Base virtual function implementation
+ }
+ };
+
+ class Derived : public Base {
+ public:
+ __device__ void virtualFunction() override {
+ // Derived virtual function implementation
+ }
+ };
+
+ __global__ void kernel() {
+ Derived obj;
+ Base* basePtr =
+ basePtr->virtualFunction(); // Allowed since obj is constructed in
device code
+ }
>From 1e9ab73e4aa0d39322ea16ba59e5feabf16ca778 Mon Sep 17 00:00:00 2001
From: "Yaxun (Sam) Liu"
Date: Sat, 7 Oct 2023 10:37:54 -0400
Subject: [PATCH 2/2] Add documentation about rdc mode
and possible way to improve virtual function support
---
clang/docs/HIPSupport.rst | 44 ---
1 file changed, 37 insertions(+), 7 deletions(-)
diff --git a/clang/docs/HIPSupport.rst b/clang/docs/HIPSupport.rst
index 63c16c0051153a0..7aa3741749e70c1 100644
--- a/clang/docs/HIPSupport.rst
+++ b/clang/docs/HIPSupport.rst
@@ -176,8 +176,36 @@ Predefined Macros
* - ``HIP_API_PER_THREAD_DEFAULT_STREAM``
- Alias to ``__HIP_API_PER_THREAD_DEFAULT_STREAM__``. Deprecated.
-Function Pointers Support in Clang with HIP
-===
+Compilation Modes
+=
+
+Each HIP source file contains intertwined device and host code. Depending on
the chosen compilation mode by the compiler options ``-fno-gpu-rdc`` and
``-fgpu-rdc``, these portions of code are compiled differently.
+
+Device Code Compilation
+---
+
+**``-fno-gpu-rdc`` Mode (default)**:
+
+- Compiles to a self-contained, fully linked offloading device binary for each
offloading device architecture.
+- Device code within a Translation Unit (TU) cannot call functions located in
another TU.
+
+**``-fgpu-rdc`` Mode**:
+
+- Compiles to a bitcode for each GPU architecture.
+- For each offloading device architecture, the bitcode from different TUs are
linked together to
[clang] [HIP] Document func ptr and virtual func (PR #68126)
@@ -176,3 +176,65 @@ Predefined Macros * - ``HIP_API_PER_THREAD_DEFAULT_STREAM`` - Alias to ``__HIP_API_PER_THREAD_DEFAULT_STREAM__``. Deprecated. +Function Pointers Support in Clang with HIP +=== + +Function pointers' support varies with the usage mode in Clang with HIP. The following table provides an overview of the support status across different use-cases and modes. + +.. list-table:: Function Pointers Support Overview + :widths: 25 25 25 + :header-rows: 1 + + * - Use Case + - ``-fno-gpu-rdc`` Mode (default) + - ``-fgpu-rdc`` Mode + * - Defined and used in the same TU + - Supported + - Supported + * - Defined in one TU and used in another TU + - Not Supported + - Supported + +In the ``-fno-gpu-rdc`` mode, the compiler calculates the resource usage of kernels based only on functions present within the same Translation Unit (TU). This mode does not support the use of function pointers defined in a different TU due to the possibility of incorrect resource usage calculations, leading to undefined behavior. + +On the other hand, the ``-fgpu-rdc`` mode allows the definition and use of function pointers across different TUs, as resource usage calculations can accommodate functions from disparate TUs. + +Virtual Function Support in Clang with HIP +== + +In Clang with HIP, support for calling virtual functions of an object in device or host code is contingent on where the object is constructed. yxsamliu wrote: will do https://github.com/llvm/llvm-project/pull/68126 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [HIP] Document func ptr and virtual func (PR #68126)
@@ -176,3 +176,70 @@ Predefined Macros
* - ``HIP_API_PER_THREAD_DEFAULT_STREAM``
- Alias to ``__HIP_API_PER_THREAD_DEFAULT_STREAM__``. Deprecated.
+Function Pointers Support in Clang with HIP
+===
+
+Function pointers' support varies with the usage mode in Clang with HIP. The
following table provides an overview of the support status across different
use-cases and modes.
+
+.. list-table:: Function Pointers Support Overview
+ :widths: 25 25 25
+ :header-rows: 1
+
+ * - Use Case
+ - ``-fno-gpu-rdc`` Mode (default)
+ - ``-fgpu-rdc`` Mode
+ * - Defined and used in the same TU
+ - Supported
+ - Supported
+ * - Defined in one TU and used in another TU
+ - Not Supported
+ - Supported
+
+In the ``-fno-gpu-rdc`` mode, the compiler calculates the resource usage of
kernels based only on functions present within the same Translation Unit (TU).
This mode does not support the use of function pointers defined in a different
TU due to the possibility of incorrect resource usage calculations, leading to
undefined behavior.
+
+On the other hand, the ``-fgpu-rdc`` mode allows the definition and use of
function pointers across different TUs, as resource usage calculations can
accommodate functions from disparate TUs.
+
+Virtual Function Support in Clang with HIP
+==
+
+In Clang with HIP, support for calling virtual functions of an object in
device or host code is contingent on where the object is constructed.
+
+- **Constructed in Device Code**: Virtual functions of an object can be called
in device code if the object is constructed in device code.
+- **Constructed in Host Code**: Virtual functions of an object can be called
in host code if the object is constructed in host code.
+
+In other scenarios, calling virtual functions is not allowed.
+
+Explanation
+---
+
+An object constructed on the device side contains a pointer to the virtual
function table on the device side, which is not accessible in host code, and
vice versa. Thus, trying to invoke virtual functions from a context different
from where the object was constructed will be disallowed because the
appropriate virtual table cannot be accessed.
+
+Example Usage
+-
+
+.. code-block:: c++
+
+ class Base {
+ public:
+ __device__ virtual void virtualFunction() {
+ // Base virtual function implementation
+ }
+ };
+
+ class Derived : public Base {
+ public:
+ __device__ void virtualFunction() override {
+ // Derived virtual function implementation
+ }
+ };
+
+ __global__ void kernel() {
+ Derived obj;
+ Base* basePtr =
+ basePtr->virtualFunction(); // Allowed since obj is constructed in
device code
+ }
+
+Note
+
+
+Ensure to construct objects in the appropriate context (host or device)
depending on where you intend to call their virtual functions to avoid runtime
errors.
yxsamliu wrote:
I added a separate section about -fgpu-rdc and -fno-gpu-rdc mode
https://github.com/llvm/llvm-project/pull/68126
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [HIP] Document func ptr and virtual func (PR #68126)
@@ -176,3 +176,65 @@ Predefined Macros * - ``HIP_API_PER_THREAD_DEFAULT_STREAM`` - Alias to ``__HIP_API_PER_THREAD_DEFAULT_STREAM__``. Deprecated. +Function Pointers Support in Clang with HIP +=== + +Function pointers' support varies with the usage mode in Clang with HIP. The following table provides an overview of the support status across different use-cases and modes. + +.. list-table:: Function Pointers Support Overview + :widths: 25 25 25 + :header-rows: 1 + + * - Use Case + - ``-fno-gpu-rdc`` Mode (default) + - ``-fgpu-rdc`` Mode + * - Defined and used in the same TU + - Supported + - Supported + * - Defined in one TU and used in another TU + - Not Supported + - Supported + +In the ``-fno-gpu-rdc`` mode, the compiler calculates the resource usage of kernels based only on functions present within the same Translation Unit (TU). This mode does not support the use of function pointers defined in a different TU due to the possibility of incorrect resource usage calculations, leading to undefined behavior. yxsamliu wrote: will do https://github.com/llvm/llvm-project/pull/68126 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [HIP] Document func ptr and virtual func (PR #68126)
@@ -176,3 +176,65 @@ Predefined Macros * - ``HIP_API_PER_THREAD_DEFAULT_STREAM`` - Alias to ``__HIP_API_PER_THREAD_DEFAULT_STREAM__``. Deprecated. +Function Pointers Support in Clang with HIP +=== + +Function pointers' support varies with the usage mode in Clang with HIP. The following table provides an overview of the support status across different use-cases and modes. + +.. list-table:: Function Pointers Support Overview + :widths: 25 25 25 + :header-rows: 1 + + * - Use Case + - ``-fno-gpu-rdc`` Mode (default) + - ``-fgpu-rdc`` Mode + * - Defined and used in the same TU + - Supported + - Supported + * - Defined in one TU and used in another TU + - Not Supported + - Supported + +In the ``-fno-gpu-rdc`` mode, the compiler calculates the resource usage of kernels based only on functions present within the same Translation Unit (TU). This mode does not support the use of function pointers defined in a different TU due to the possibility of incorrect resource usage calculations, leading to undefined behavior. Artem-B wrote: I'd mention that in `-fno-gpu-rdc` each TU compiles to a fully linked GPU executable, vs an object file with `-fgpu-rdc`. This should give more context for reasoning about accessibility of various data bits. https://github.com/llvm/llvm-project/pull/68126 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [HIP] Document func ptr and virtual func (PR #68126)
@@ -176,3 +176,65 @@ Predefined Macros * - ``HIP_API_PER_THREAD_DEFAULT_STREAM`` - Alias to ``__HIP_API_PER_THREAD_DEFAULT_STREAM__``. Deprecated. +Function Pointers Support in Clang with HIP +=== + +Function pointers' support varies with the usage mode in Clang with HIP. The following table provides an overview of the support status across different use-cases and modes. + +.. list-table:: Function Pointers Support Overview + :widths: 25 25 25 + :header-rows: 1 + + * - Use Case + - ``-fno-gpu-rdc`` Mode (default) + - ``-fgpu-rdc`` Mode + * - Defined and used in the same TU + - Supported + - Supported + * - Defined in one TU and used in another TU + - Not Supported + - Supported + +In the ``-fno-gpu-rdc`` mode, the compiler calculates the resource usage of kernels based only on functions present within the same Translation Unit (TU). This mode does not support the use of function pointers defined in a different TU due to the possibility of incorrect resource usage calculations, leading to undefined behavior. + +On the other hand, the ``-fgpu-rdc`` mode allows the definition and use of function pointers across different TUs, as resource usage calculations can accommodate functions from disparate TUs. + +Virtual Function Support in Clang with HIP +== + +In Clang with HIP, support for calling virtual functions of an object in device or host code is contingent on where the object is constructed. Artem-B wrote: We should also mention how mixing host and device virtual functions is expected to work. AFAICT, vtable populates wrong-side virtual functions with nullptr: https://godbolt.org/z/4f6hvjMcj https://github.com/llvm/llvm-project/pull/68126 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [HIP] Document func ptr and virtual func (PR #68126)
https://github.com/yxsamliu updated
https://github.com/llvm/llvm-project/pull/68126
>From 87e7bba138e2d702d0e2433f2b81c891fec4d2bd Mon Sep 17 00:00:00 2001
From: "Yaxun (Sam) Liu"
Date: Tue, 3 Oct 2023 12:21:10 -0400
Subject: [PATCH] [HIP] Document func ptr and virtual func
Document clang support for function pointers and virtual functions with HIP
---
clang/docs/HIPSupport.rst | 62 +++
1 file changed, 62 insertions(+)
diff --git a/clang/docs/HIPSupport.rst b/clang/docs/HIPSupport.rst
index 8b4649733a9c777..63c16c0051153a0 100644
--- a/clang/docs/HIPSupport.rst
+++ b/clang/docs/HIPSupport.rst
@@ -176,3 +176,65 @@ Predefined Macros
* - ``HIP_API_PER_THREAD_DEFAULT_STREAM``
- Alias to ``__HIP_API_PER_THREAD_DEFAULT_STREAM__``. Deprecated.
+Function Pointers Support in Clang with HIP
+===
+
+Function pointers' support varies with the usage mode in Clang with HIP. The
following table provides an overview of the support status across different
use-cases and modes.
+
+.. list-table:: Function Pointers Support Overview
+ :widths: 25 25 25
+ :header-rows: 1
+
+ * - Use Case
+ - ``-fno-gpu-rdc`` Mode (default)
+ - ``-fgpu-rdc`` Mode
+ * - Defined and used in the same TU
+ - Supported
+ - Supported
+ * - Defined in one TU and used in another TU
+ - Not Supported
+ - Supported
+
+In the ``-fno-gpu-rdc`` mode, the compiler calculates the resource usage of
kernels based only on functions present within the same Translation Unit (TU).
This mode does not support the use of function pointers defined in a different
TU due to the possibility of incorrect resource usage calculations, leading to
undefined behavior.
+
+On the other hand, the ``-fgpu-rdc`` mode allows the definition and use of
function pointers across different TUs, as resource usage calculations can
accommodate functions from disparate TUs.
+
+Virtual Function Support in Clang with HIP
+==
+
+In Clang with HIP, support for calling virtual functions of an object in
device or host code is contingent on where the object is constructed.
+
+- **Constructed in Device Code**: Virtual functions of an object can be called
in device code if the object is constructed in device code.
+- **Constructed in Host Code**: Virtual functions of an object can be called
in host code if the object is constructed in host code.
+
+In other scenarios, calling virtual functions is not allowed.
+
+Explanation
+---
+
+An object constructed on the device side contains a pointer to the virtual
function table on the device side, which is not accessible in host code, and
vice versa. Thus, trying to invoke virtual functions from a context different
from where the object was constructed will be disallowed because the
appropriate virtual table cannot be accessed.
+
+Example Usage
+-
+
+.. code-block:: c++
+
+ class Base {
+ public:
+ __device__ virtual void virtualFunction() {
+ // Base virtual function implementation
+ }
+ };
+
+ class Derived : public Base {
+ public:
+ __device__ void virtualFunction() override {
+ // Derived virtual function implementation
+ }
+ };
+
+ __global__ void kernel() {
+ Derived obj;
+ Base* basePtr =
+ basePtr->virtualFunction(); // Allowed since obj is constructed in
device code
+ }
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [HIP] Document func ptr and virtual func (PR #68126)
https://github.com/b-sumner commented: This looks fine to me. https://github.com/llvm/llvm-project/pull/68126 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [HIP] Document func ptr and virtual func (PR #68126)
https://github.com/yxsamliu updated
https://github.com/llvm/llvm-project/pull/68126
>From 9dd5da61a18ca642245c966125b2d4e26eed5b61 Mon Sep 17 00:00:00 2001
From: "Yaxun (Sam) Liu"
Date: Tue, 3 Oct 2023 12:21:10 -0400
Subject: [PATCH] [HIP] Document func ptr and virtual func
Document clang support for function pointers and virtual functions with HIP
---
clang/docs/HIPSupport.rst | 62 +++
1 file changed, 62 insertions(+)
diff --git a/clang/docs/HIPSupport.rst b/clang/docs/HIPSupport.rst
index 8b4649733a9c777..87e45b64e3a6754 100644
--- a/clang/docs/HIPSupport.rst
+++ b/clang/docs/HIPSupport.rst
@@ -176,3 +176,65 @@ Predefined Macros
* - ``HIP_API_PER_THREAD_DEFAULT_STREAM``
- Alias to ``__HIP_API_PER_THREAD_DEFAULT_STREAM__``. Deprecated.
+Function Pointers Support in Clang with HIP
+===
+
+Function pointers' support varies with the usage mode in Clang with HIP. The
following table provides an overview of the support status across different
use-cases and modes.
+
+.. list-table:: Function Pointers Support Overview
+ :widths: 25 25 25
+ :header-rows: 1
+
+ * - Use Case
+ - ``-fno-gpu-rdc`` Mode (default)
+ - ``-fgpu-rdc`` Mode
+ * - Defined and used in the same TU
+ - Supported
+ - Supported
+ * - Defined in one TU and used in another TU
+ - Not Supported
+ - Supported
+
+In the ``-fno-gpu-rdc`` mode, the compiler calculates the resource usage of
kernels based only on functions present within the same Translation Unit (TU).
This mode does not support the use of function pointers defined in a different
TU due to the possibility of incorrect resource usage calculations, leading to
undefined behavior.
+
+On the other hand, the ``-fgpu-rdc`` mode allows the definition and use of
function pointers across different TUs, as resource usage calculations can
accommodate functions from disparate TUs.
+
+Virtual Function Support in Clang with HIP
+==
+
+In Clang with HIP, support for calling virtual functions of an object in
device or host code is contingent on where the object is constructed.
+
+- **Constructed in Device Code**: Virtual functions of an object can be called
in device code if the object is constructed in device code.
+- **Constructed in Host Code**: Virtual functions of an object can be called
in host code if the object is constructed in host code.
+
+In other scenarios, calling virtual functions is not allowed.
+
+Explanation
+---
+
+An object constructed on the device side contains a pointer to the virtual
function table on the device side, which is not accessible in host code, and
vice versa. Thus, trying to invoke virtual functions from a context different
from where the object was constructed will be disallowed because the
appropriate virtual table cannot be accessed.
+
+Example Usage
+-
+
+.. code-block:: c++
+
+ class Base {
+ public:
+ __device__ virtual void virtualFunction() {
+ // Base virtual function implementation
+ }
+ };
+
+ class Derived : public Base {
+ public:
+ __device__ void virtualFunction() override {
+ // Derived virtual function implementation
+ }
+ };
+
+ __global__ void kernel() {
+ Derived obj;
+ Base* basePtr =
+ basePtr->virtualFunction(); // Allowed since obj is constructed in
device code
+ }
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [HIP] Document func ptr and virtual func (PR #68126)
@@ -176,3 +176,70 @@ Predefined Macros
* - ``HIP_API_PER_THREAD_DEFAULT_STREAM``
- Alias to ``__HIP_API_PER_THREAD_DEFAULT_STREAM__``. Deprecated.
+Function Pointers Support in Clang with HIP
+===
+
+Function pointers' support varies with the usage mode in Clang with HIP. The
following table provides an overview of the support status across different
use-cases and modes.
+
+.. list-table:: Function Pointers Support Overview
+ :widths: 25 25 25
+ :header-rows: 1
+
+ * - Use Case
+ - ``-fno-gpu-rdc`` Mode (default)
+ - ``-fgpu-rdc`` Mode
+ * - Defined and used in the same TU
+ - Supported
+ - Supported
+ * - Defined in one TU and used in another TU
+ - Not Supported
+ - Supported
+
+In the ``-fno-gpu-rdc`` mode, the compiler calculates the resource usage of
kernels based only on functions present within the same Translation Unit (TU).
This mode does not support the use of function pointers defined in a different
TU due to the possibility of incorrect resource usage calculations, leading to
undefined behavior.
+
+On the other hand, the ``-fgpu-rdc`` mode allows the definition and use of
function pointers across different TUs, as resource usage calculations can
accommodate functions from disparate TUs.
+
+Virtual Function Support in Clang with HIP
+==
+
+In Clang with HIP, support for calling virtual functions of an object in
device or host code is contingent on where the object is constructed.
+
+- **Constructed in Device Code**: Virtual functions of an object can be called
in device code if the object is constructed in device code.
+- **Constructed in Host Code**: Virtual functions of an object can be called
in host code if the object is constructed in host code.
+
+In other scenarios, calling virtual functions is not allowed.
+
+Explanation
+---
+
+An object constructed on the device side contains a pointer to the virtual
function table on the device side, which is not accessible in host code, and
vice versa. Thus, trying to invoke virtual functions from a context different
from where the object was constructed will be disallowed because the
appropriate virtual table cannot be accessed.
+
+Example Usage
+-
+
+.. code-block:: c++
+
+ class Base {
+ public:
+ __device__ virtual void virtualFunction() {
+ // Base virtual function implementation
+ }
+ };
+
+ class Derived : public Base {
+ public:
+ __device__ void virtualFunction() override {
+ // Derived virtual function implementation
+ }
+ };
+
+ __global__ void kernel() {
+ Derived obj;
+ Base* basePtr =
+ basePtr->virtualFunction(); // Allowed since obj is constructed in
device code
+ }
+
+Note
+
+
+Ensure to construct objects in the appropriate context (host or device)
depending on where you intend to call their virtual functions to avoid runtime
errors.
yxsamliu wrote:
will remove
https://github.com/llvm/llvm-project/pull/68126
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [HIP] Document func ptr and virtual func (PR #68126)
@@ -176,3 +176,70 @@ Predefined Macros
* - ``HIP_API_PER_THREAD_DEFAULT_STREAM``
- Alias to ``__HIP_API_PER_THREAD_DEFAULT_STREAM__``. Deprecated.
+Function Pointers Support in Clang with HIP
+===
+
+Function pointers' support varies with the usage mode in Clang with HIP. The
following table provides an overview of the support status across different
use-cases and modes.
+
+.. list-table:: Function Pointers Support Overview
+ :widths: 25 25 25
+ :header-rows: 1
+
+ * - Use Case
+ - ``-fno-gpu-rdc`` Mode (default)
+ - ``-fgpu-rdc`` Mode
+ * - Defined and used in the same TU
+ - Supported
+ - Supported
+ * - Defined in one TU and used in another TU
+ - Not Supported
+ - Supported
+
+In the ``-fno-gpu-rdc`` mode, the compiler calculates the resource usage of
kernels based only on functions present within the same Translation Unit (TU).
This mode does not support the use of function pointers defined in a different
TU due to the possibility of incorrect resource usage calculations, leading to
undefined behavior.
+
+On the other hand, the ``-fgpu-rdc`` mode allows the definition and use of
function pointers across different TUs, as resource usage calculations can
accommodate functions from disparate TUs.
+
+Virtual Function Support in Clang with HIP
+==
+
+In Clang with HIP, support for calling virtual functions of an object in
device or host code is contingent on where the object is constructed.
+
+- **Constructed in Device Code**: Virtual functions of an object can be called
in device code if the object is constructed in device code.
+- **Constructed in Host Code**: Virtual functions of an object can be called
in host code if the object is constructed in host code.
+
+In other scenarios, calling virtual functions is not allowed.
+
+Explanation
+---
+
+An object constructed on the device side contains a pointer to the virtual
function table on the device side, which is not accessible in host code, and
vice versa. Thus, trying to invoke virtual functions from a context different
from where the object was constructed will be disallowed because the
appropriate virtual table cannot be accessed.
+
+Example Usage
+-
+
+.. code-block:: c++
+
+ class Base {
+ public:
+ __device__ virtual void virtualFunction() {
+ // Base virtual function implementation
+ }
+ };
+
+ class Derived : public Base {
+ public:
+ __device__ void virtualFunction() override {
+ // Derived virtual function implementation
+ }
+ };
+
+ __global__ void kernel() {
+ Derived obj;
+ Base* basePtr =
+ basePtr->virtualFunction(); // Allowed since obj is constructed in
device code
+ }
+
+Note
+
+
+Ensure to construct objects in the appropriate context (host or device)
depending on where you intend to call their virtual functions to avoid runtime
errors.
b-sumner wrote:
Not sure that this note is needed given the preceding information. If kept,
replace "Ensure to construct" with "Ensure that objects are constructed"...
https://github.com/llvm/llvm-project/pull/68126
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [HIP] Document func ptr and virtual func (PR #68126)
llvmbot wrote:
@llvm/pr-subscribers-clang
Changes
Document clang support for function pointers and virtual functions with HIP
---
Full diff: https://github.com/llvm/llvm-project/pull/68126.diff
1 Files Affected:
- (modified) clang/docs/HIPSupport.rst (+67)
``diff
diff --git a/clang/docs/HIPSupport.rst b/clang/docs/HIPSupport.rst
index 8b4649733a9c777..7a4db10789f2c90 100644
--- a/clang/docs/HIPSupport.rst
+++ b/clang/docs/HIPSupport.rst
@@ -176,3 +176,70 @@ Predefined Macros
* - ``HIP_API_PER_THREAD_DEFAULT_STREAM``
- Alias to ``__HIP_API_PER_THREAD_DEFAULT_STREAM__``. Deprecated.
+Function Pointers Support in Clang with HIP
+===
+
+Function pointers' support varies with the usage mode in Clang with HIP. The
following table provides an overview of the support status across different
use-cases and modes.
+
+.. list-table:: Function Pointers Support Overview
+ :widths: 25 25 25
+ :header-rows: 1
+
+ * - Use Case
+ - ``-fno-gpu-rdc`` Mode (default)
+ - ``-fgpu-rdc`` Mode
+ * - Defined and used in the same TU
+ - Supported
+ - Supported
+ * - Defined in one TU and used in another TU
+ - Not Supported
+ - Supported
+
+In the ``-fno-gpu-rdc`` mode, the compiler calculates the resource usage of
kernels based only on functions present within the same Translation Unit (TU).
This mode does not support the use of function pointers defined in a different
TU due to the possibility of incorrect resource usage calculations, leading to
undefined behavior.
+
+On the other hand, the ``-fgpu-rdc`` mode allows the definition and use of
function pointers across different TUs, as resource usage calculations can
accommodate functions from disparate TUs.
+
+Virtual Function Support in Clang with HIP
+==
+
+In Clang with HIP, support for calling virtual functions of an object in
device or host code is contingent on where the object is constructed.
+
+- **Constructed in Device Code**: Virtual functions of an object can be called
in device code if the object is constructed in device code.
+- **Constructed in Host Code**: Virtual functions of an object can be called
in host code if the object is constructed in host code.
+
+In other scenarios, calling virtual functions is not allowed.
+
+Explanation
+---
+
+An object constructed on the device side contains a pointer to the virtual
function table on the device side, which is not accessible in host code, and
vice versa. Thus, trying to invoke virtual functions from a context different
from where the object was constructed will be disallowed because the
appropriate virtual table cannot be accessed.
+
+Example Usage
+-
+
+.. code-block:: c++
+
+ class Base {
+ public:
+ __device__ virtual void virtualFunction() {
+ // Base virtual function implementation
+ }
+ };
+
+ class Derived : public Base {
+ public:
+ __device__ void virtualFunction() override {
+ // Derived virtual function implementation
+ }
+ };
+
+ __global__ void kernel() {
+ Derived obj;
+ Base* basePtr =
+ basePtr->virtualFunction(); // Allowed since obj is constructed in
device code
+ }
+
+Note
+
+
+Ensure to construct objects in the appropriate context (host or device)
depending on where you intend to call their virtual functions to avoid runtime
errors.
``
https://github.com/llvm/llvm-project/pull/68126
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [HIP] Document func ptr and virtual func (PR #68126)
https://github.com/yxsamliu created
https://github.com/llvm/llvm-project/pull/68126
Document clang support for function pointers and virtual functions with HIP
>From 659831a00a74a05dfd2d77c98544e02fee88e7bd Mon Sep 17 00:00:00 2001
From: "Yaxun (Sam) Liu"
Date: Tue, 3 Oct 2023 12:21:10 -0400
Subject: [PATCH] [HIP] Document func ptr and virtual func
Document clang support for function pointers and virtual functions with HIP
---
clang/docs/HIPSupport.rst | 67 +++
1 file changed, 67 insertions(+)
diff --git a/clang/docs/HIPSupport.rst b/clang/docs/HIPSupport.rst
index 8b4649733a9c777..7a4db10789f2c90 100644
--- a/clang/docs/HIPSupport.rst
+++ b/clang/docs/HIPSupport.rst
@@ -176,3 +176,70 @@ Predefined Macros
* - ``HIP_API_PER_THREAD_DEFAULT_STREAM``
- Alias to ``__HIP_API_PER_THREAD_DEFAULT_STREAM__``. Deprecated.
+Function Pointers Support in Clang with HIP
+===
+
+Function pointers' support varies with the usage mode in Clang with HIP. The
following table provides an overview of the support status across different
use-cases and modes.
+
+.. list-table:: Function Pointers Support Overview
+ :widths: 25 25 25
+ :header-rows: 1
+
+ * - Use Case
+ - ``-fno-gpu-rdc`` Mode (default)
+ - ``-fgpu-rdc`` Mode
+ * - Defined and used in the same TU
+ - Supported
+ - Supported
+ * - Defined in one TU and used in another TU
+ - Not Supported
+ - Supported
+
+In the ``-fno-gpu-rdc`` mode, the compiler calculates the resource usage of
kernels based only on functions present within the same Translation Unit (TU).
This mode does not support the use of function pointers defined in a different
TU due to the possibility of incorrect resource usage calculations, leading to
undefined behavior.
+
+On the other hand, the ``-fgpu-rdc`` mode allows the definition and use of
function pointers across different TUs, as resource usage calculations can
accommodate functions from disparate TUs.
+
+Virtual Function Support in Clang with HIP
+==
+
+In Clang with HIP, support for calling virtual functions of an object in
device or host code is contingent on where the object is constructed.
+
+- **Constructed in Device Code**: Virtual functions of an object can be called
in device code if the object is constructed in device code.
+- **Constructed in Host Code**: Virtual functions of an object can be called
in host code if the object is constructed in host code.
+
+In other scenarios, calling virtual functions is not allowed.
+
+Explanation
+---
+
+An object constructed on the device side contains a pointer to the virtual
function table on the device side, which is not accessible in host code, and
vice versa. Thus, trying to invoke virtual functions from a context different
from where the object was constructed will be disallowed because the
appropriate virtual table cannot be accessed.
+
+Example Usage
+-
+
+.. code-block:: c++
+
+ class Base {
+ public:
+ __device__ virtual void virtualFunction() {
+ // Base virtual function implementation
+ }
+ };
+
+ class Derived : public Base {
+ public:
+ __device__ void virtualFunction() override {
+ // Derived virtual function implementation
+ }
+ };
+
+ __global__ void kernel() {
+ Derived obj;
+ Base* basePtr =
+ basePtr->virtualFunction(); // Allowed since obj is constructed in
device code
+ }
+
+Note
+
+
+Ensure to construct objects in the appropriate context (host or device)
depending on where you intend to call their virtual functions to avoid runtime
errors.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
