History log of /llvm-project/clang/test/OpenMP/declare_target_codegen.cpp (Results 1 – 25 of 65)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
Revision tags: llvmorg-21-init
# 13dcc95d 28-Jan-2025 Joseph Huber <huberjn@outlook.com>

[Offload] Rework offloading entry type to be more generic (#124018)

Summary:
The previous offloading entry type did not fit the current use-cases
very well. This widens it and adds a version to pr

[Offload] Rework offloading entry type to be more generic (#124018)

Summary:
The previous offloading entry type did not fit the current use-cases
very well. This widens it and adds a version to prevent further
annoyances. It also includes the kind to better sort who's using it.

The first 64-bytes are reserved as zero so the OpenMP runtime can detect
the old format for binary compatibilitry.

show more ...


Revision tags: llvmorg-19.1.7, llvmorg-19.1.6, llvmorg-19.1.5, llvmorg-19.1.4, llvmorg-19.1.3, llvmorg-19.1.2, llvmorg-19.1.1, llvmorg-19.1.0, llvmorg-19.1.0-rc4, llvmorg-19.1.0-rc3, llvmorg-19.1.0-rc2, llvmorg-19.1.0-rc1, llvmorg-20-init, llvmorg-18.1.8, llvmorg-18.1.7, llvmorg-18.1.6
# 7c1d9b15 05-May-2024 Fangrui Song <i@maskray.me>

[test] %clang_cc1: remove redundant actions


Revision tags: 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
# 237adfca 10-Nov-2023 Joseph Huber <jhuber6@vols.utk.edu>

[OpenMP] Rework handling of global ctor/dtors in OpenMP (#71739)

Summary:
This patch reworks how we handle global constructors in OpenMP.
Previously, we emitted individual kernels that were all regi

[OpenMP] Rework handling of global ctor/dtors in OpenMP (#71739)

Summary:
This patch reworks how we handle global constructors in OpenMP.
Previously, we emitted individual kernels that were all registered and
called individually. In order to provide more generic support, this
patch moves all handling of this to the target backend and the runtime
plugin. This has the benefit of supporting the GNU extensions for
constructors an destructors, removing a class of failures related to
shared library destruction order, and allows targets other than OpenMP
to use the same support without needing to change the frontend.

This is primarily done by calling kernels that the backend emits to
iterate a list of ctor / dtor functions. For x64, this is automatic and
we get it for free with the standard `dlopen` handling. For AMDGPU, we
emit `amdgcn.device.init` and `amdgcn.device.fini` functions which
handle everything atuomatically and simply need to be called. For NVPTX,
a patch https://github.com/llvm/llvm-project/pull/71549 provides the
kernels to call, but the runtime needs to set up the array manually by
pulling out all the known constructor / destructor functions.

One concession that this patch requires is the change that for GPU
targets in OpenMP offloading we will use `llvm.global_dtors` instead of
using `atexit`. This is because `atexit` is a separate runtime function
that does not mesh well with the handling we're trying to do here. This
should be equivalent in all cases except for cases where we would need
to destruct manually such as:

```
struct S { ~S() { foo(); } };
void foo() {
static S s;
}
```

However this is broken in many other ways on the GPU, so it is not
regressing any support, simply increasing the scope of what we can
handle.

This changes the handling of ctors / dtors. This patch now outputs a
information message regarding the deprecation if the old format is used.
This will be completely removed in a later release.

Depends on: https://github.com/llvm/llvm-project/pull/71549

show more ...


# b8cbc5c0 01-Nov-2023 Johannes Doerfert <johannes@jdoerfert.de>

[OpenMP] Introduce the KernelLaunchEnvironment as implicit argument (#70401)

The KernelEnvironment is for compile time information about a kernel. It
allows the compiler to feed information to the

[OpenMP] Introduce the KernelLaunchEnvironment as implicit argument (#70401)

The KernelEnvironment is for compile time information about a kernel. It
allows the compiler to feed information to the runtime. The
KernelLaunchEnvironment is for dynamic information *per* kernel launch.
It allows the rutime to feed information to the kernel that is not
shared with other invocations of the kernel. The first use case is to
replace the globals that synchronize teams reductions with per-launch
versions. This allows concurrent teams reductions. More uses cases will
follow, e.g., per launch memory pools.

Fixes: https://github.com/llvm/llvm-project/issues/70249

show more ...


Revision tags: llvmorg-17.0.4, llvmorg-17.0.3
# 85feb934 09-Oct-2023 Joseph Huber <jhuber6@vols.utk.edu>

[OpenMP] Fix setting visibility on declare target variables

Summary:
A previous patch changed the logic to force external visibliity on
declare target variables. This is because they need to be expo

[OpenMP] Fix setting visibility on declare target variables

Summary:
A previous patch changed the logic to force external visibliity on
declare target variables. This is because they need to be exported in
the dynamic symbol table to be usable as the standard depicts. However,
the logic was always setting the visibility to `protected`, which would
override some symbols. For example, when calling `libc` functions for
CPU offloading. This patch changes the logic to only fire if the
variable has hidden visibliity to start with.

show more ...


# 1d959f93 05-Oct-2023 Joseph Huber <35342157+jhuber6@users.noreply.github.com>

[OpenMP] Prevent AMDGPU from overriding visibility on DT_nohost variables (#68264)

Summary:
There's some logic in the AMDGPU target that manually resets the
requested visibility of certain variables

[OpenMP] Prevent AMDGPU from overriding visibility on DT_nohost variables (#68264)

Summary:
There's some logic in the AMDGPU target that manually resets the
requested visibility of certain variables. This was triggering when we
set a constant variable in OpenMP. However, we shouldn't do this for
OpenMP when the variable has the `nohost` type. That implies that the
variable is not visible to the host and therefore does not need to be
visible, so we should respect the original value of it.

show more ...


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
# 141c4e7a 26-Jul-2023 Joseph Huber <jhuber6@vols.utk.edu>

[OpenMP] Do not always emit unused extern variables

Currently, the precense of the OpenMP target declare metadata requires
that we always codegen a global declaration. This is undesirable in the
cas

[OpenMP] Do not always emit unused extern variables

Currently, the precense of the OpenMP target declare metadata requires
that we always codegen a global declaration. This is undesirable in the
case that we could defer or omit this declaration as is common with
unused extern variables. This is important as it allows us, in the
runtime, to rely on static linking semantics to omit unused symbols so
they are not included when the user links it in.

This patch changes the check for always emitting these variables.
Because of this we also need to extend this logic to the generation of
the offloading entries. This has the result of derring the offload entry
generation to the canonical definitoin. So we are effectively assuming
whoever owns the storage for this variable will perform that operation.
This makes an exception for `link` attributes as those require their own
special handling.

Let me know if this is sound in the implementation, I do not have the
largest view of the standards here.

Fixes: https://github.com/llvm/llvm-project/issues/64133

Reviewed By: tianshilei1992

Differential Revision: https://reviews.llvm.org/D156368

show more ...


Revision tags: llvmorg-18-init
# 63ca93c7 06-Jul-2023 Sergio Afonso <safonsof@amd.com>

[OpenMP][OMPIRBuilder] Rename IsEmbedded and IsTargetCodegen flags

This patch renames the `OpenMPIRBuilderConfig` flags to reduce confusion over
their meaning. `IsTargetCodegen` becomes `IsGPU`, whe

[OpenMP][OMPIRBuilder] Rename IsEmbedded and IsTargetCodegen flags

This patch renames the `OpenMPIRBuilderConfig` flags to reduce confusion over
their meaning. `IsTargetCodegen` becomes `IsGPU`, whereas `IsEmbedded` becomes
`IsTargetDevice`. The `-fopenmp-is-device` compiler option is also renamed to
`-fopenmp-is-target-device` and the `omp.is_device` MLIR attribute is renamed
to `omp.is_target_device`. Getters and setters of all these renamed properties
are also updated accordingly. Many unit tests have been updated to use the new
names, but an alias for the `-fopenmp-is-device` option is created so that
external programs do not stop working after the name change.

`IsGPU` is set when the target triple is AMDGCN or NVIDIA PTX, and it is only
valid if `IsTargetDevice` is specified as well. `IsTargetDevice` is set by the
`-fopenmp-is-target-device` compiler frontend option, which is only added to
the OpenMP device invocation for offloading-enabled programs.

Differential Revision: https://reviews.llvm.org/D154591

show more ...


# 1d699bf2 20-Jun-2023 Joseph Huber <jhuber6@vols.utk.edu>

[OpenMP] Always apply target declarations to canonical definitions

This patch changes the handling of OpenMP to add the device attributes
to the canonical definitions when we encounter a non-canonic

[OpenMP] Always apply target declarations to canonical definitions

This patch changes the handling of OpenMP to add the device attributes
to the canonical definitions when we encounter a non-canonical
definition. Previously, the following code would not work because it
would find the non-canonical definition first which would then not be
used anywhere else.

```
int x;
extern int x;
```

This patch now adds the attribute to both of them. This allows us to
perform the following operation if, for example, there were an
implementation of `stderr` on the device.

```
#include <stdio.h>

// List of libc symbols supported on the device.
extern FILE *stderr;
```

Unfortunately I cannot think of an equivalent solution to HIP / CUDA
device declarations as those are done with simple attributes. Attributes
themselves cannot be used to affect a definition once its canonical
definition has already been seen. Some help on that front would be
appreciated.

Fixes https://github.com/llvm/llvm-project/issues/63355

Reviewed By: ABataev

Differential Revision: https://reviews.llvm.org/D153369

show more ...


Revision tags: llvmorg-16.0.6, llvmorg-16.0.5, llvmorg-16.0.4, llvmorg-16.0.3, llvmorg-16.0.2, llvmorg-16.0.1, llvmorg-16.0.0, llvmorg-16.0.0-rc4, llvmorg-16.0.0-rc3, llvmorg-16.0.0-rc2, llvmorg-16.0.0-rc1, llvmorg-17-init, llvmorg-15.0.7, llvmorg-15.0.6, llvmorg-15.0.5, llvmorg-15.0.4
# 67f8521c 28-Oct-2022 Jan Sjodin <jan_sjodin@yahoo.com>

[OpenMP] [OMPIRBuilder] Create a new datatype to hold the unique target region info

Re-apply of: 3d0e9edd8e53fb72e85084f4170513159212839a
Reverted in: 0cb65b0a585c8b3d4a8a2aefe994a8fc907934f8

A fun

[OpenMP] [OMPIRBuilder] Create a new datatype to hold the unique target region info

Re-apply of: 3d0e9edd8e53fb72e85084f4170513159212839a
Reverted in: 0cb65b0a585c8b3d4a8a2aefe994a8fc907934f8

A function parameter was using the wrong type 'llvm::TargetRegion' instead of
'const llvm:: TargetRegion&', which caused the error in the address sanitizer.
The correct type is now used.

This patch puts the individual target region information attributes into a
struct so that the nested mappings are not needed and passing the information
around is simplified.

Reviewed By: jdoerfert, mikerice

Differential Revision: https://reviews.llvm.org/D136601

show more ...


# 0cb65b0a 27-Oct-2022 Kevin Athey <kda@google.com>

Revert "[OpenMP] [OMPIRBuilder] Create a new datatype to hold the unique target region info"

This reverts commit 3d0e9edd8e53fb72e85084f4170513159212839a.

Breaking HWASAN buildbot:
https://lab.llvm

Revert "[OpenMP] [OMPIRBuilder] Create a new datatype to hold the unique target region info"

This reverts commit 3d0e9edd8e53fb72e85084f4170513159212839a.

Breaking HWASAN buildbot:
https://lab.llvm.org/buildbot/#/builders/236/builds/786

Shown by targetted builds breaking at this patch:
Built at this patch: https://lab.llvm.org/buildbot/#/builders/236/builds/803
Built at prior patch: https://lab.llvm.org/buildbot/#/builders/236/builds/804

show more ...


# 3d0e9edd 24-Oct-2022 Jan Sjodin <jan_sjodin@yahoo.com>

[OpenMP] [OMPIRBuilder] Create a new datatype to hold the unique target region info

This patch puts the individual target region information attributes into a
struct so that the nested mappings are

[OpenMP] [OMPIRBuilder] Create a new datatype to hold the unique target region info

This patch puts the individual target region information attributes into a
struct so that the nested mappings are not needed and passing the information
around is simplified.

Reviewed By: jdoerfert, mikerice

Differential Revision: https://reviews.llvm.org/D136601

show more ...


# 8c1449a8 18-Oct-2022 Joseph Huber <jhuber6@vols.utk.edu>

[OpenMP] Make kernels have protected visibility

This patch changes the kernels generated by OpenMP to have protected
visibility. This is unlikely to change anything functionally. However,
protected

[OpenMP] Make kernels have protected visibility

This patch changes the kernels generated by OpenMP to have protected
visibility. This is unlikely to change anything functionally. However,
protected visibility better matches the behaviour of these GPU kernels.
We do not expect any pending shared library load to preempt these
kernels so we can specify a more restrictive visibility.

Reviewed By: jdoerfert

Differential Revision: https://reviews.llvm.org/D136198

show more ...


Revision tags: llvmorg-15.0.3
# a290f3c8 07-Oct-2022 Nikita Popov <npopov@redhat.com>

[OpenMP] Convert tests to opaque pointers (NFC)

Conversion performed using the script at:
https://gist.github.com/nikic/98357b71fd67756b0f064c9517b62a34

These are only tests where no manual fixup w

[OpenMP] Convert tests to opaque pointers (NFC)

Conversion performed using the script at:
https://gist.github.com/nikic/98357b71fd67756b0f064c9517b62a34

These are only tests where no manual fixup was required.

show more ...


Revision tags: working, llvmorg-15.0.2, llvmorg-15.0.1, llvmorg-15.0.0
# 74742147 02-Sep-2022 Fangrui Song <i@maskray.me>

[test] Change cc1 -fvisibility to -fvisibility=


Revision tags: llvmorg-15.0.0-rc3, llvmorg-15.0.0-rc2, llvmorg-15.0.0-rc1, llvmorg-16-init, llvmorg-14.0.6, llvmorg-14.0.5, llvmorg-14.0.4, llvmorg-14.0.3, llvmorg-14.0.2, llvmorg-14.0.1
# 532dc62b 07-Apr-2022 Nikita Popov <npopov@redhat.com>

[OpaquePtrs][Clang] Add -no-opaque-pointers to tests (NFC)

This adds -no-opaque-pointers to clang tests whose output will
change when opaque pointers are enabled by default. This is
intended to be p

[OpaquePtrs][Clang] Add -no-opaque-pointers to tests (NFC)

This adds -no-opaque-pointers to clang tests whose output will
change when opaque pointers are enabled by default. This is
intended to be part of the migration approach described in
https://discourse.llvm.org/t/enabling-opaque-pointers-by-default/61322/9.

The patch has been produced by replacing %clang_cc1 with
%clang_cc1 -no-opaque-pointers for tests that fail with opaque
pointers enabled. Worth noting that this doesn't cover all tests,
there's a remaining ~40 tests not using %clang_cc1 that will need
a followup change.

Differential Revision: https://reviews.llvm.org/D123115

show more ...


# 3c6d32ec 25-Mar-2022 Joseph Huber <jhuber6@vols.utk.edu>

[OpenMP] Make Ctor / Dtor functions have external visibility

The default construction of constructor functions by LLVM tends to make
them have internal linkage. When we call a ctor / dtor function i

[OpenMP] Make Ctor / Dtor functions have external visibility

The default construction of constructor functions by LLVM tends to make
them have internal linkage. When we call a ctor / dtor function in the
target region we are actually creating a kernel that is called at
registration. Because the ctor is a kernel we need to make sure it's
externally visible so we can actually call it. This prevented AMDGPU
from correctly using constructors while NVPTX could use them simply
because it ignored internal visibility.

Reviewed By: JonChesterfield

Differential Revision: https://reviews.llvm.org/D122504

show more ...


# b9f67d44 24-Mar-2022 Joseph Huber <jhuber6@vols.utk.edu>

[OpenMP] Replace device kernel linkage with weak_odr

Currently the device kernels all have weak linkage to prevent linkage
errors on multiple defintions. However, this prevents some optimizations
fr

[OpenMP] Replace device kernel linkage with weak_odr

Currently the device kernels all have weak linkage to prevent linkage
errors on multiple defintions. However, this prevents some optimizations
from adequately analyzing them because of the nature of weak linkage.
This patch replaces the weak linkage with weak_odr linkage so we can
statically assert that multiple declarations of the same kernel will
have the same definition.

Reviewed By: jdoerfert

Differential Revision: https://reviews.llvm.org/D122443

show more ...


Revision tags: llvmorg-14.0.0, llvmorg-14.0.0-rc4, llvmorg-14.0.0-rc3, llvmorg-14.0.0-rc2, llvmorg-14.0.0-rc1, llvmorg-15-init, llvmorg-13.0.1, llvmorg-13.0.1-rc3
# 0dfe9532 20-Jan-2022 Joseph Huber <jhuber6@vols.utk.edu>

[OpenMP] Change default visibility to protected for device declarations

This patch changes the special-case handling of visibility when
compiling for an OpenMP target offloading device. This was ori

[OpenMP] Change default visibility to protected for device declarations

This patch changes the special-case handling of visibility when
compiling for an OpenMP target offloading device. This was orignally
added as a precaution against the bug encountered in PR41826 when
symbols in the device were being preempted by shared library symbols.
This should instead be done by making the visibility protected by default.
With protected visibility we are asserting that the symbols on the device
will never be preempted or preempt another symbol pending a shared library
load.

Reviewed By: JonChesterfield

Differential Revision: https://reviews.llvm.org/D117806

show more ...


# ca6c9e43 14-Jan-2022 Joseph Huber <jhuber6@vols.utk.edu>

[OpenMP] Remove hidden visibility for declare target variables

This patch changes the visiblity of variables declared within a declare
target directive. Variable declarations within a declare target

[OpenMP] Remove hidden visibility for declare target variables

This patch changes the visiblity of variables declared within a declare
target directive. Variable declarations within a declare target
directive need to be externally visible to the plugin for initialization
or reading. Previously this would cause runtime errors where the named
global could not be found because it was not included in the symbol
table.

Reviewed By: jdoerfert

Differential Revision: https://reviews.llvm.org/D117362

show more ...


# 8fc24de9 18-Jan-2022 Joseph Huber <jhuber6@vols.utk.edu>

Revert "[OpenMP] Remove hidden visibility for declare target variables"

Reverting to investigate break on AMDPGU. This reverts commit
d081bfcd17c1c704776a0964d239f19f6acde93d.


# d081bfcd 14-Jan-2022 Joseph Huber <jhuber6@vols.utk.edu>

[OpenMP] Remove hidden visibility for declare target variables

This patch changes the visiblity of variables declared within a declare
target directive. Variable declarations within a declare target

[OpenMP] Remove hidden visibility for declare target variables

This patch changes the visiblity of variables declared within a declare
target directive. Variable declarations within a declare target
directive need to be externally visible to the plugin for initialization
or reading. Previously this would cause runtime errors where the named
global could not be found because it was not included in the symbol
table.

Reviewed By: jdoerfert

Differential Revision: https://reviews.llvm.org/D117362

show more ...


# 1b1c8d83 16-Jan-2022 hyeongyu kim <gusrb406@snu.ac.kr>

[Clang/Test]: Rename enable_noundef_analysis to disable-noundef-analysis and turn it off by default

Turning on `enable_noundef_analysis` flag allows better codegen by removing freeze instructions.
I

[Clang/Test]: Rename enable_noundef_analysis to disable-noundef-analysis and turn it off by default

Turning on `enable_noundef_analysis` flag allows better codegen by removing freeze instructions.
I modified clang by renaming `enable_noundef_analysis` flag to `disable-noundef-analysis` and turning it off by default.

Test updates are made as a separate patch: D108453

Reviewed By: eugenis

Differential Revision: https://reviews.llvm.org/D105169

show more ...


Revision tags: llvmorg-13.0.1-rc2, llvmorg-13.0.1-rc1
# fd9b0999 08-Nov-2021 hyeongyu kim <gusrb406@snu.ac.kr>

Revert "[Clang/Test]: Rename enable_noundef_analysis to disable-noundef-analysis and turn it off by default"

This reverts commit aacfbb953eb705af2ecfeb95a6262818fa85dd92.

Revert "Fix lit test failu

Revert "[Clang/Test]: Rename enable_noundef_analysis to disable-noundef-analysis and turn it off by default"

This reverts commit aacfbb953eb705af2ecfeb95a6262818fa85dd92.

Revert "Fix lit test failures in CodeGenCoroutines"

This reverts commit 63fff0f5bffe20fa2c84a45a41161afa0043cb34.

show more ...


# aacfbb95 15-Oct-2021 hyeongyukim <gusrb406@snu.ac.kr>

[Clang/Test]: Rename enable_noundef_analysis to disable-noundef-analysis and turn it off by default

Turning on `enable_noundef_analysis` flag allows better codegen by removing freeze instructions.
I

[Clang/Test]: Rename enable_noundef_analysis to disable-noundef-analysis and turn it off by default

Turning on `enable_noundef_analysis` flag allows better codegen by removing freeze instructions.
I modified clang by renaming `enable_noundef_analysis` flag to `disable-noundef-analysis` and turning it off by default.

Test updates are made as a separate patch: D108453

Reviewed By: eugenis

Differential Revision: https://reviews.llvm.org/D105169

[Clang/Test]: Rename enable_noundef_analysis to disable-noundef-analysis and turn it off by default (2)

This patch updates test files after D105169.
Autogenerated test codes are changed by `utils/update_cc_test_checks.py,` and non-autogenerated test codes are changed as follows:

(1) I wrote a python script that (partially) updates the tests using regex: {F18594904} The script is not perfect, but I believe it gives hints about which patterns are updated to have `noundef` attached.

(2) The remaining tests are updated manually.

Reviewed By: eugenis

Differential Revision: https://reviews.llvm.org/D108453

Resolve lit failures in clang after 8ca4b3e's land

Fix lit test failures in clang-ppc* and clang-x64-windows-msvc

Fix missing failures in clang-ppc64be* and retry fixing clang-x64-windows-msvc

Fix internal_clone(aarch64) inline assembly

show more ...


123