|
Revision tags: llvmorg-18.1.8, llvmorg-18.1.7, llvmorg-18.1.6, llvmorg-18.1.5, llvmorg-18.1.4, llvmorg-18.1.3, llvmorg-18.1.2, llvmorg-18.1.1, llvmorg-18.1.0, llvmorg-18.1.0-rc4, llvmorg-18.1.0-rc3, llvmorg-18.1.0-rc2, llvmorg-18.1.0-rc1, llvmorg-19-init, llvmorg-17.0.6, llvmorg-17.0.5, llvmorg-17.0.4, llvmorg-17.0.3 |
|
| #
6d30d945 |
| 05-Oct-2023 |
Kiran Chandramohan <kiran.chandramohan@arm.com> |
[Flang][OpenMP] NFC: Port three tests with minimal changes to HLFIR flow
These are modified versions of tests from flang/test/Lower/OpenMP/FIR.
|
|
Revision tags: llvmorg-17.0.2, llvmorg-17.0.1, llvmorg-17.0.0, llvmorg-17.0.0-rc4, llvmorg-17.0.0-rc3, llvmorg-17.0.0-rc2, llvmorg-17.0.0-rc1, llvmorg-18-init |
|
| #
debdfc0a |
| 29-Jun-2023 |
Sergio Afonso <safonsof@amd.com> |
[Flang][OpenMP][MLIR] Filter emitted code depending on declare target and device
This patch adds support for selecting which functions are lowered to LLVM IR
from MLIR depending on declare target in
[Flang][OpenMP][MLIR] Filter emitted code depending on declare target and device
This patch adds support for selecting which functions are lowered to LLVM IR
from MLIR depending on declare target information and whether host or device
code is being generated.
The approach proposed by this patch is to perform the filtering in two stages:
- An MLIR transformation pass, which is added to the Flang translation flow
after the `OMPEarlyOutliningPass`. The functions that are kept are those
that match the OpenMP processor (host or device) the compiler invocation
is targeting, according to the presence of the `-fopenmp-is-target-device`
compiler option and declare target information. All functions contaning an
`omp.target` are also kept, regardless of the declare target information of
the function, due to the need for keeping target regions visible for both
host and device compilation.
- A filtering step during translation to LLVM IR, which is peformed for those
functions that were kept because of the presence of a target region inside.
If the targeted OpenMP processor does not match the declare target
information of the function, then it is removed from the LLVM IR after its
contents have been processed and translated. Since they should only contain
an omp.target operation which, in turn, should have been outlined into
another LLVM IR function, the wrapper can be deleted at that point.
Depends on D150328 and D150329.
Differential Revision: https://reviews.llvm.org/D147641
show more ...
|
| #
e909a2c1 |
| 13-Jul-2023 |
Andrew Gozillon <Andrew.Gozillon@amd.com> |
[Flang][OpenMP][Lower] Program level implicit SAVE variable handling for declare target
This is an attempt at mimicing the method in which
threadprivate handles the following type of variables:
pro
[Flang][OpenMP][Lower] Program level implicit SAVE variable handling for declare target
This is an attempt at mimicing the method in which
threadprivate handles the following type of variables:
program main
integer :: i
!$omp declare target to(i)
end
Which essentially generates a GlobalOp for the variable (which
would normally only be an alloca) when it's instantiated. The
main difference is there is no operation generated within the
function, instead the declare target attribute is appended
later within handleDeclareTarget.
Reviewers: kiranchandramohan
Differential Revision: https://reviews.llvm.org/D152037
show more ...
|