You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: clang/docs/HIPSupport.rst
+90Lines changed: 90 additions & 0 deletions
Original file line number
Diff line number
Diff line change
@@ -176,3 +176,93 @@ Predefined Macros
176
176
* - ``HIP_API_PER_THREAD_DEFAULT_STREAM``
177
177
- Alias to ``__HIP_API_PER_THREAD_DEFAULT_STREAM__``. Deprecated.
178
178
179
+
Compilation Modes
180
+
=================
181
+
182
+
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.
183
+
184
+
Device Code Compilation
185
+
-----------------------
186
+
187
+
**``-fno-gpu-rdc`` Mode (default)**:
188
+
189
+
- Compiles to a self-contained, fully linked offloading device binary for each offloading device architecture.
190
+
- Device code within a Translation Unit (TU) cannot call functions located in another TU.
191
+
192
+
**``-fgpu-rdc`` Mode**:
193
+
194
+
- Compiles to a bitcode for each GPU architecture.
195
+
- For each offloading device architecture, the bitcode from different TUs are linked together to create a single offloading device binary.
196
+
- Device code in one TU can call functions located in another TU.
197
+
198
+
Host Code Compilation
199
+
---------------------
200
+
201
+
**Both Modes**:
202
+
203
+
- Compiles to a relocatable object for each TU.
204
+
- These relocatable objects are then linked together.
205
+
- Host code within a TU can call host functions and launch kernels from another TU.
206
+
207
+
Function Pointers Support
208
+
=========================
209
+
210
+
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.
211
+
212
+
.. list-table:: Function Pointers Support Overview
213
+
:widths: 25 25 25
214
+
:header-rows: 1
215
+
216
+
* - Use Case
217
+
- ``-fno-gpu-rdc`` Mode (default)
218
+
- ``-fgpu-rdc`` Mode
219
+
* - Defined and used in the same TU
220
+
- Supported
221
+
- Supported
222
+
* - Defined in one TU and used in another TU
223
+
- Not Supported
224
+
- Supported
225
+
226
+
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.
227
+
228
+
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.
229
+
230
+
Virtual Function Support
231
+
========================
232
+
233
+
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.
234
+
235
+
- **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.
236
+
- **Constructed in Host Code**: Virtual functions of an object can be called in host code if the object is constructed in host code.
237
+
238
+
In other scenarios, calling virtual functions is not allowed.
239
+
240
+
Explanation
241
+
-----------
242
+
243
+
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.
244
+
245
+
Example Usage
246
+
-------------
247
+
248
+
.. code-block:: c++
249
+
250
+
class Base {
251
+
public:
252
+
__device__ virtual void virtualFunction() {
253
+
// Base virtual function implementation
254
+
}
255
+
};
256
+
257
+
class Derived : public Base {
258
+
public:
259
+
__device__ void virtualFunction() override {
260
+
// Derived virtual function implementation
261
+
}
262
+
};
263
+
264
+
__global__ void kernel() {
265
+
Derived obj;
266
+
Base* basePtr = &obj;
267
+
basePtr->virtualFunction(); // Allowed since obj is constructed in device code
0 commit comments