Author: Joseph Huber Date: 2024-02-07T13:03:31-06:00 New Revision: 347ab99a5c6d096beb7378794c6255dca2a866e6
URL: https://github.com/llvm/llvm-project/commit/347ab99a5c6d096beb7378794c6255dca2a866e6 DIFF: https://github.com/llvm/llvm-project/commit/347ab99a5c6d096beb7378794c6255dca2a866e6.diff LOG: [Clang][Docs] Fix trailing whitespace warnings Added: Modified: clang/docs/ClangLinkerWrapper.rst clang/docs/OffloadingDesign.rst Removed: ################################################################################ diff --git a/clang/docs/ClangLinkerWrapper.rst b/clang/docs/ClangLinkerWrapper.rst index 1e851b0aa0619..6d7770b50e726 100644 --- a/clang/docs/ClangLinkerWrapper.rst +++ b/clang/docs/ClangLinkerWrapper.rst @@ -64,19 +64,19 @@ only for the linker wrapper will be forwarded to the wrapped linker job. Relocatable Linking =================== -The ``clang-linker-wrapper`` handles linking embedded device code and then -registering it with the appropriate runtime. Normally, this is only done when -the executable is created so other files containing device code can be linked -together. This can be somewhat problematic for users who wish to ship static -libraries that contain offloading code to users without a compatible offloading +The ``clang-linker-wrapper`` handles linking embedded device code and then +registering it with the appropriate runtime. Normally, this is only done when +the executable is created so other files containing device code can be linked +together. This can be somewhat problematic for users who wish to ship static +libraries that contain offloading code to users without a compatible offloading toolchain. -When using a relocatable link with ``-r``, the ``clang-linker-wrapper`` will -perform the device linking and registration eagerly. This will remove the -embedded device code and register it correctly with the runtime. Semantically, -this is similar to creating a shared library object. If standard relocatable -linking is desired, simply do not run the binaries through the -``clang-linker-wrapper``. This will simply append the embedded device code so +When using a relocatable link with ``-r``, the ``clang-linker-wrapper`` will +perform the device linking and registration eagerly. This will remove the +embedded device code and register it correctly with the runtime. Semantically, +this is similar to creating a shared library object. If standard relocatable +linking is desired, simply do not run the binaries through the +``clang-linker-wrapper``. This will simply append the embedded device code so that it can be linked later. Example diff --git a/clang/docs/OffloadingDesign.rst b/clang/docs/OffloadingDesign.rst index 04319cd869b19..13bb924a77ad0 100644 --- a/clang/docs/OffloadingDesign.rst +++ b/clang/docs/OffloadingDesign.rst @@ -474,27 +474,27 @@ We can see the steps created by clang to generate the offloading code using the Relocatable Linking ------------------- -The offloading compilation pipeline normally will defer the final device linking -and runtime registration until the ``clang-linker-wrapper`` is run to create the -executable. This is the standard behaviour when compiling for OpenMP offloading -or CUDA and HIP in ``-fgpu-rdc`` mode. However, there are some cases where the -user may wish to perform this device handling prematurely. This is described in +The offloading compilation pipeline normally will defer the final device linking +and runtime registration until the ``clang-linker-wrapper`` is run to create the +executable. This is the standard behaviour when compiling for OpenMP offloading +or CUDA and HIP in ``-fgpu-rdc`` mode. However, there are some cases where the +user may wish to perform this device handling prematurely. This is described in the :doc:`linker wrapper documentation<ClangLinkerWrapper>`. -Effectively, this allows the user to handle offloading specific linking ahead of -time when shipping objects or static libraries. This can be thought of as -performing a standard ``-fno-gpu-rdc`` compilation on a subset of object files. -This can be useful to reduce link time, prevent users from interacting with the +Effectively, this allows the user to handle offloading specific linking ahead of +time when shipping objects or static libraries. This can be thought of as +performing a standard ``-fno-gpu-rdc`` compilation on a subset of object files. +This can be useful to reduce link time, prevent users from interacting with the library's device code, or for shipping libraries to incompatible compilers. -Normally, if a relocatable link is done using ``clang -r`` it will simply merge -the ``.llvm.offloading`` sections which will then be linked later when the -executable is created. However, if the ``-r`` flag is used with the offloading -toolchain, it will perform the device linking and registration phases and then +Normally, if a relocatable link is done using ``clang -r`` it will simply merge +the ``.llvm.offloading`` sections which will then be linked later when the +executable is created. However, if the ``-r`` flag is used with the offloading +toolchain, it will perform the device linking and registration phases and then merge the registration code into the final relocatable object file. -The following example shows how using the relocatable link with the offloading -pipeline can create a static library with offloading code that can be +The following example shows how using the relocatable link with the offloading +pipeline can create a static library with offloading code that can be redistributed without requiring any additional handling. .. code-block:: console _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits