[flang-commits] [flang] [flang][NFC] Strip trailing whitespace from markdown files (2 of 2) (PR #173253)
via flang-commits
flang-commits at lists.llvm.org
Mon Dec 22 04:38:11 PST 2025
llvmbot wrote:
<!--LLVM PR SUMMARY COMMENT-->
@llvm/pr-subscribers-openacc
Author: Tarun Prabhu (tarunprabhu)
<details>
<summary>Changes</summary>
Strip trailing whitespace from the remaining markdown files. This completes the sequence of NFC commits performing the cleanup of trailing whitespace from markdown files.
---
Patch is 47.49 KiB, truncated to 20.00 KiB below, full version: https://github.com/llvm/llvm-project/pull/173253.diff
18 Files Affected:
- (modified) flang/docs/OpenACC-descriptor-management.md (+9-9)
- (modified) flang/docs/OpenACC.md (+5-5)
- (modified) flang/docs/OpenMP-declare-target.md (+113-113)
- (modified) flang/docs/OpenMP-descriptor-management.md (+34-34)
- (modified) flang/docs/OpenMP-semantics.md (+3-3)
- (modified) flang/docs/OptionComparison.md (+10-10)
- (modified) flang/docs/Overview.md (+10-10)
- (modified) flang/docs/ParallelMultiImageFortranRuntime.md (+4-5)
- (modified) flang/docs/ParameterizedDerivedTypes.md (+1-1)
- (modified) flang/docs/ParserCombinators.md (+3-3)
- (modified) flang/docs/Parsing.md (+4-4)
- (modified) flang/docs/Preprocessing.md (+3-3)
- (modified) flang/docs/PullRequestChecklist.md (+1-1)
- (modified) flang/docs/RuntimeDescriptor.md (+3-3)
- (modified) flang/docs/RuntimeEnvironment.md (+3-3)
- (modified) flang/docs/RuntimeTypeInfo.md (+3-3)
- (modified) flang/docs/Semantics.md (+3-3)
- (modified) flang/docs/Unsigned.md (+3-3)
``````````diff
diff --git a/flang/docs/OpenACC-descriptor-management.md b/flang/docs/OpenACC-descriptor-management.md
index 7a6e6b4346348..a9618667af387 100644
--- a/flang/docs/OpenACC-descriptor-management.md
+++ b/flang/docs/OpenACC-descriptor-management.md
@@ -53,7 +53,7 @@ program main
real, pointer :: t1(:,:)
nullify(d%p)
allocate(t1(2,2))
-
+
! 2.7.9:
! Allocates the memory for object 'd' on the device.
! The descriptor member of 'd' is a NULL descriptor,
@@ -62,9 +62,9 @@ program main
! The descriptor storage is created on the device
! just as part of the object 'd' storage.
!$acc enter data create(d)
-
+
d%p => t1
-
+
! 2.7.7:
! Pointer d%p is not present on the device, so copyin
! action is performed for the data pointed to by the pointer:
@@ -80,7 +80,7 @@ program main
! from the host values of the corresponding members.
! * The attachment counter of 'd%p' is set to 1.
!$acc enter data copyin(d%p)
-
+
! 2.7.7:
! Pointer d%p is already present on the device, so no copyin
! action is performed.
@@ -89,12 +89,12 @@ program main
! during the previous attachment, only its attachment counter
! is incremented to 2.
!$acc enter data copyin(d%p)
-
+
! 3.2.29:
! The detach action is performed. According to 2.7.2 the attachment
! counter of d%p is decremented to 1.
call acc_detach(d%p)
-
+
! 3.2.29:
! The detach action is performed. According to 2.7.2 the attachment
! counter of d%p is decremented to 0, which initiates an update
@@ -102,7 +102,7 @@ program main
! pointer in the local memory.
! We will discuss this in more detail below.
call acc_detach(d%p)
-
+
! The following construct will fail, because the 'd%p' descriptor's
! base_addr is now the host address not accessible on the device.
! Without the second 'acc_detach' it will work correctly.
@@ -111,7 +111,7 @@ program main
!$acc end serial
```
-Let's discuss in more detail what happens during the second `acc_detach`.
+Let's discuss in more detail what happens during the second `acc_detach`.
OpenACC 2.6.4:
@@ -255,7 +255,7 @@ Due to `d%p` reference in the `present` clause of the `serial` region, the compi
In the case of POINTER dummy argument, if the descriptor storage is not explicitly created in the user code, the pointer attachment may not happen due to 2.7.2:
> 1693 If the pointer var is in shared memory or is not present in the current device memory, or if the
-> 1694 address to which var points is not present in the current device memory, no action is taken.
+> 1694 address to which var points is not present in the current device memory, no action is taken.
Example:
diff --git a/flang/docs/OpenACC.md b/flang/docs/OpenACC.md
index 6d384f93ae216..f1fe69e57bf37 100644
--- a/flang/docs/OpenACC.md
+++ b/flang/docs/OpenACC.md
@@ -1,9 +1,9 @@
-<!--===- docs/Extensions.md
-
+<!--===- docs/Extensions.md
+
Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
See https://llvm.org/LICENSE.txt for license information.
SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
-
+
-->
# OpenACC in Flang
@@ -23,9 +23,9 @@ local:
warning instead of an error as other compiler accepts it.
* The `if` clause accepts scalar integer expression in addition to scalar
logical expression.
-* `!$acc routine` directive can be placed at the top level.
+* `!$acc routine` directive can be placed at the top level.
* `!$acc cache` directive accepts scalar variable.
-* The `!$acc declare` directive accepts assumed size array arguments for
+* The `!$acc declare` directive accepts assumed size array arguments for
`deviceptr` and `present` clauses.
* The OpenACC specification disallows a variable appearing multiple times in
clauses of `!$acc declare` directives for a function, subroutine, program,
diff --git a/flang/docs/OpenMP-declare-target.md b/flang/docs/OpenMP-declare-target.md
index 478db2d004c87..ac7fec5e83495 100644
--- a/flang/docs/OpenMP-declare-target.md
+++ b/flang/docs/OpenMP-declare-target.md
@@ -18,9 +18,9 @@ local:
## Introduction to Declare Target
In OpenMP `declare target` is a directive that can be applied to a function or
-variable (primarily global) to notate to the compiler that it should be
-generated in a particular device's environment. In essence whether something
-should be emitted for host or device, or both. An example of its usage for
+variable (primarily global) to notate to the compiler that it should be
+generated in a particular device's environment. In essence whether something
+should be emitted for host or device, or both. An example of its usage for
both data and functions can be seen below.
```Fortran
@@ -37,9 +37,9 @@ program main
end program
```
-In the above example, we create a variable in a separate module, mark it
-as `declare target` and then map it, embedding it into the device IR and
-assigning to it.
+In the above example, we create a variable in a separate module, mark it
+as `declare target` and then map it, embedding it into the device IR and
+assigning to it.
```Fortran
@@ -57,28 +57,28 @@ end program
```
In the above example, we are stating that a function is required on device
-utilising `declare target`, and that we will not be utilising it on host,
-so we are in theory free to remove or ignore it there. A user could also
-in this case, leave off the `declare target` from the function and it
-would be implicitly marked `declare target any` (for both host and device),
+utilising `declare target`, and that we will not be utilising it on host,
+so we are in theory free to remove or ignore it there. A user could also
+in this case, leave off the `declare target` from the function and it
+would be implicitly marked `declare target any` (for both host and device),
as it's been utilised within a target region.
## Declare Target as represented in the OpenMP Dialect
-In the OpenMP Dialect `declare target` is not represented by a specific
-`operation`. Instead, it's an OpenMP dialect specific `attribute` that can be
-applied to any operation in any dialect, which helps to simplify the
-utilisation of it. Rather than replacing or modifying existing global or
+In the OpenMP Dialect `declare target` is not represented by a specific
+`operation`. Instead, it's an OpenMP dialect specific `attribute` that can be
+applied to any operation in any dialect, which helps to simplify the
+utilisation of it. Rather than replacing or modifying existing global or
function `operations` in a dialect, it applies to it as extra metadata that
-the lowering can use in different ways as is necessary.
+the lowering can use in different ways as is necessary.
-The `attribute` is composed of multiple fields representing the clauses you
-would find on the `declare target` directive i.e. device type (`nohost`,
-`any`, `host`) or the capture clause (`link` or `to`). A small example of
+The `attribute` is composed of multiple fields representing the clauses you
+would find on the `declare target` directive i.e. device type (`nohost`,
+`any`, `host`) or the capture clause (`link` or `to`). A small example of
`declare target` applied to a Fortran `real` can be found below:
```
-fir.global internal @_QFEi {omp.declare_target =
+fir.global internal @_QFEi {omp.declare_target =
#omp.declaretarget<device_type = (any), capture_clause = (to)>} : f32 {
%0 = fir.undefined f32
fir.has_value %0 : f32
@@ -87,12 +87,12 @@ fir.global internal @_QFEi {omp.declare_target =
This would look similar for function style `operations`.
-The application and access of this attribute is aided by an OpenMP Dialect
-MLIR Interface named `DeclareTargetInterface`, which can be utilised on
+The application and access of this attribute is aided by an OpenMP Dialect
+MLIR Interface named `DeclareTargetInterface`, which can be utilised on
operations to access the appropriate interface functions, e.g.:
```C++
-auto declareTargetGlobal =
+auto declareTargetGlobal =
llvm::dyn_cast<mlir::omp::DeclareTargetInterface>(Op.getOperation());
declareTargetGlobal.isDeclareTarget();
```
@@ -100,127 +100,127 @@ declareTargetGlobal.isDeclareTarget();
## Declare Target Fortran OpenMP Lowering
The initial lowering of `declare target` to MLIR for both use-cases is done
-inside of the usual OpenMP lowering in flang/lib/Lower/OpenMP.cpp. However,
-some direct calls to `declare target` related functions from Flang's
+inside of the usual OpenMP lowering in flang/lib/Lower/OpenMP.cpp. However,
+some direct calls to `declare target` related functions from Flang's
lowering bridge in flang/lib/Lower/Bridge.cpp are made.
-The marking of operations with the declare target attribute happens in two
-phases, the second one optional and contingent on the first failing. The
-initial phase happens when the declare target directive and its clauses
+The marking of operations with the declare target attribute happens in two
+phases, the second one optional and contingent on the first failing. The
+initial phase happens when the declare target directive and its clauses
are initially processed, with the primary data gathering for the directive and
clause happening in a function called `getDeclareTargetInfo`. This is then used
-to feed the `markDeclareTarget` function, which does the actual marking
+to feed the `markDeclareTarget` function, which does the actual marking
utilising the `DeclareTargetInterface`. If it encounters a variable or function
that has been marked twice over multiple directives with two differing device
types (e.g. `host`, `nohost`), then it will swap the device type to `any`.
-Whenever we invoke `genFIR` on an `OpenMPDeclarativeConstruct` from the
-lowering bridge, we are also invoking another function called
+Whenever we invoke `genFIR` on an `OpenMPDeclarativeConstruct` from the
+lowering bridge, we are also invoking another function called
`gatherOpenMPDeferredDeclareTargets`, which gathers information relevant to the
-application of the `declare target` attribute. This information
-includes the symbol that it should be applied to, device type clause,
+application of the `declare target` attribute. This information
+includes the symbol that it should be applied to, device type clause,
and capture clause, and it is stored in a vector that is part of the lowering
-bridge's instantiation of the `AbstractConverter`. It is only stored if we
-encounter a function or variable symbol that does not have an operation
-instantiated for it yet. This cannot happen as part of the
-initial marking as we must store this data in the lowering bridge and we
-only have access to the abstract version of the converter via the OpenMP
-lowering.
-
-The information produced by the first phase is used in the second phase,
-which is a form of deferred processing of the `declare target` marked
-operations that have delayed generation and cannot be proccessed in the
-first phase. The main notable case this occurs currently is when a
-Fortran function interface has been marked. This is
-done via the function
+bridge's instantiation of the `AbstractConverter`. It is only stored if we
+encounter a function or variable symbol that does not have an operation
+instantiated for it yet. This cannot happen as part of the
+initial marking as we must store this data in the lowering bridge and we
+only have access to the abstract version of the converter via the OpenMP
+lowering.
+
+The information produced by the first phase is used in the second phase,
+which is a form of deferred processing of the `declare target` marked
+operations that have delayed generation and cannot be proccessed in the
+first phase. The main notable case this occurs currently is when a
+Fortran function interface has been marked. This is
+done via the function
`markOpenMPDeferredDeclareTargetFunctions`, which is called from the lowering
-bridge at the end of the lowering process allowing us to mark those where
-possible. It iterates over the data previously gathered by
-`gatherOpenMPDeferredDeclareTargets`
-checking if any of the recorded symbols have now had their corresponding
-operations instantiated and applying the declare target attribute where
-possible utilising `markDeclareTarget`. However, it must be noted that it
-is still possible for operations not to be generated for certain symbols,
-in particular the case of function interfaces that are not directly used
-or defined within the current module. This means we cannot emit errors in
-the case of left-over unmarked symbols. These must (and should) be caught
+bridge at the end of the lowering process allowing us to mark those where
+possible. It iterates over the data previously gathered by
+`gatherOpenMPDeferredDeclareTargets`
+checking if any of the recorded symbols have now had their corresponding
+operations instantiated and applying the declare target attribute where
+possible utilising `markDeclareTarget`. However, it must be noted that it
+is still possible for operations not to be generated for certain symbols,
+in particular the case of function interfaces that are not directly used
+or defined within the current module. This means we cannot emit errors in
+the case of left-over unmarked symbols. These must (and should) be caught
by the initial semantic analysis.
NOTE: `declare target` can be applied to implicit `SAVE` attributed variables.
However, by default Flang does not represent these as `GlobalOp`'s, which means
we cannot tag and lower them as `declare target` normally. Instead, similarly
-to the way `threadprivate` handles these cases, we raise and initialize the
+to the way `threadprivate` handles these cases, we raise and initialize the
variable as an internal `GlobalOp` and apply the attribute. This occurs in the
flang/lib/Lower/OpenMP.cpp function `genDeclareTargetIntGlobal`.
## Declare Target Transformation Passes for Flang
-There are currently two passes within Flang that are related to the processing
+There are currently two passes within Flang that are related to the processing
of `declare target`:
* `MarkDeclareTarget` - This pass is in charge of marking functions captured
(called from) in `target` regions or other `declare target` marked functions as
-`declare target`. It does so recursively, i.e. nested calls will also be
-implicitly marked. It currently will try to mark things as conservatively as
+`declare target`. It does so recursively, i.e. nested calls will also be
+implicitly marked. It currently will try to mark things as conservatively as
possible, e.g. if captured in a `target` region it will apply `nohost`, unless
-it encounters a `host` `declare target` in which case it will apply the `any`
-device type. Functions are handled similarly, except we utilise the parent's
+it encounters a `host` `declare target` in which case it will apply the `any`
+device type. Functions are handled similarly, except we utilise the parent's
device type where possible.
* `FunctionFiltering` - This is executed after the `MarkDeclareTarget`
pass, and its job is to conservatively remove host functions from
-the module where possible when compiling for the device. This helps make
-sure that most incompatible code for the host is not lowered for the
-device. Host functions with `target` regions in them need to be preserved
-(e.g. for lowering the `target region`(s) inside). Otherwise, it removes
-any function marked as a `declare target host` function and any uses will be
-replaced with `undef`'s so that the remaining host code doesn't become broken.
-Host functions with `target` regions are marked with a `declare target host`
+the module where possible when compiling for the device. This helps make
+sure that most incompatible code for the host is not lowered for the
+device. Host functions with `target` regions in them need to be preserved
+(e.g. for lowering the `target region`(s) inside). Otherwise, it removes
+any function marked as a `declare target host` function and any uses will be
+replaced with `undef`'s so that the remaining host code doesn't become broken.
+Host functions with `target` regions are marked with a `declare target host`
attribute so they will be removed after outlining the target regions contained
inside.
-While this infrastructure could be generally applicable to more than just Flang,
-it is only utilised in the Flang frontend, so it resides there rather than in
-the OpenMP dialect codebase.
+While this infrastructure could be generally applicable to more than just Flang,
+it is only utilised in the Flang frontend, so it resides there rather than in
+the OpenMP dialect codebase.
## Declare Target OpenMP Dialect To LLVM-IR Lowering
-The OpenMP dialect lowering of `declare target` is done through the
-`amendOperation` flow, as it's not an `operation` but rather an
+The OpenMP dialect lowering of `declare target` is done through the
+`amendOperation` flow, as it's not an `operation` but rather an
`attribute`. This is triggered immediately after the corresponding
operation has been lowered to LLVM-IR. As it is applicable to
-different types of operations, we must specialise this function for
-each operation type that we may encounter. Currently, this is
+different types of operations, we must specialise this function for
+each operation type that we may encounter. Currently, this is
`GlobalOp`'s and `FuncOp`'s.
-`FuncOp` processing is fairly simple. When compiling for the device,
-`host` marked functions are removed, including those that could not
-be removed earlier due to having `target` directives within. This
-leaves `any`, `device` or indeterminable functions left in the
-module to lower further. When compiling for the host, no filtering is
-done because `nohost` functions must be available as a fallback
+`FuncOp` processing is fairly simple. When compiling for the device,
+`host` marked functions are removed, including those that could not
+be removed earlier due to having `target` directives within. This
+leaves `any`, `device` or indeterminable functions left in the
+module to lower further. When compiling for the host, no filtering is
+done because `nohost` functions must be available as a fallback
implementation.
-For `GlobalOp`'s, the processing is a little more complex. We
-currently leverage the `registerTargetGlobalVariable` and
-`getAddrOfDeclareTargetVar` `OMPIRBuilder` functions shared with Clang.
-These two functions invoke each other depending on the clauses and options
+For `GlobalOp`'s, the processing is a little more complex. We
+currently leverage the `registerTargetGlobalVariable` and
+`getAddrOfDeclareTargetVar` `OMPIRBuilder` functions shared with Clang.
+These two functions invoke each other depending on the clauses and options
provided to the `OMPIRBuilder` (in particular, unified shared memory). Their
-main purposes are the generation of a new global device pointer with a
-"ref_" prefix on the device and enqueuing metadata generation by the
-`OMPIRBuilder` to be produced at module finalization time. This is done
-for both host and device and it links the newly generated device global
+main purposes are the generation of a new global device pointer with a
+"ref_" prefix on the device and enqueuing metadata generation by the
+`OMPIRBuilder` to be produced at module finalization time. This is done
+for both host and device and it links the newly generated device global
pointer and the host pointer together across the two modules.
Similarly to other metadata (e.g. for `TargetOp`) that is shared across
-both host and device modules, processing of `GlobalOp`'s in the device
-needs access to the previously generated host IR file, which is done
-through another `attribute` applied to the `ModuleOp` by the compiler
-frontend. The file is loaded in and consumed by the `OMPIRBuilder` to
-populate it's `OffloadInfoManager` data structures, keeping host and
+both host and device modules, processing of `GlobalOp`'s in the device
+needs access to the previously generated host IR file, which is done
+through another `attribute` applied to the `ModuleOp` by the compiler
+frontend. The file is loaded in and consumed by the `OMPIRBuilder` to
+populate it's `OffloadInfoManager` data structures, keeping host and
device appropriately synchronised.
The se...
[truncated]
``````````
</details>
https://github.com/llvm/llvm-project/pull/173253
More information about the flang-commits
mailing list