History log of /llvm-project/clang/test/OpenMP/target_data_use_device_addr_codegen.cpp (Results 1 – 24 of 24)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
Revision tags: llvmorg-21-init, 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
# 7eca38ce 05-Sep-2024 Hari Limaye <hari.limaye@arm.com>

Reland "[clang] Add nuw attribute to GEPs (#105496)" (#107257)

Add nuw attribute to inbounds GEPs where the expression used to form the
GEP is an addition of unsigned indices.

Relands #105496, w

Reland "[clang] Add nuw attribute to GEPs (#105496)" (#107257)

Add nuw attribute to inbounds GEPs where the expression used to form the
GEP is an addition of unsigned indices.

Relands #105496, which was reverted because it exposed a miscompilation
arising from #98608. This is now fixed by #106512.

show more ...


Revision tags: llvmorg-19.1.0-rc4
# 69437a39 28-Aug-2024 Vitaly Buka <vitalybuka@google.com>

Revert "[clang] Add nuw attribute to GEPs" (#106343)

Reverts llvm/llvm-project#105496

This patch breaks:
https://lab.llvm.org/buildbot/#/builders/25/builds/1952
https://lab.llvm.org/buildbot/#/

Revert "[clang] Add nuw attribute to GEPs" (#106343)

Reverts llvm/llvm-project#105496

This patch breaks:
https://lab.llvm.org/buildbot/#/builders/25/builds/1952
https://lab.llvm.org/buildbot/#/builders/52/builds/1775

Somehow output is different with sanitizers.
Maybe non-determinism in the code?

show more ...


# 3d2fd31c 27-Aug-2024 Hari Limaye <hari.limaye@arm.com>

[clang] Add nuw attribute to GEPs (#105496)

Add nuw attribute to inbounds GEPs where the expression used to form the
GEP is an addition of unsigned indices.


Revision tags: llvmorg-19.1.0-rc3
# 94473f4d 09-Aug-2024 Hari Limaye <hari.limaye@arm.com>

[IRBuilder] Generate nuw GEPs for struct member accesses (#99538)

Generate nuw GEPs for struct member accesses, as inbounds + non-negative
implies nuw.

Regression tests are updated using update

[IRBuilder] Generate nuw GEPs for struct member accesses (#99538)

Generate nuw GEPs for struct member accesses, as inbounds + non-negative
implies nuw.

Regression tests are updated using update scripts where possible, and by
find + replace where not.

show more ...


Revision tags: llvmorg-19.1.0-rc2, llvmorg-19.1.0-rc1, llvmorg-20-init
# 32f7672a 04-Jul-2024 jyu2-git <jennifer.yu@intel.com>

[Clang][OpenMP] This is addition fix for #92210. (#94802)

Fix another runtime problem when explicit map both pointer and pointee
in target data region.

In #92210, problem is only addressed in ta

[Clang][OpenMP] This is addition fix for #92210. (#94802)

Fix another runtime problem when explicit map both pointer and pointee
in target data region.

In #92210, problem is only addressed in target region, but missing for
target data region.

The change just passing AreBothBasePtrAndPteeMapped in
generateInfoForComponentList when processing target data.

---------

Co-authored-by: Alexey Bataev <a.bataev@gmx.com>

show more ...


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
# 0113722d 07-Dec-2023 jyu2-git <jennifer.yu@intel.com>

[OpenMP] Fix runtime problem due to wrong map size. (#74692)

Currently we are missing set up-boundary address for FinalArraySection
as highests elements in partial struct data.

Currently for:
\

[OpenMP] Fix runtime problem due to wrong map size. (#74692)

Currently we are missing set up-boundary address for FinalArraySection
as highests elements in partial struct data.

Currently for:
\#pragma omp target map(D.a) map(D.b[:2])
The size is:
%a = getelementptr inbounds %struct.DataTy, ptr %D, i32 0, i32 0
%b = getelementptr inbounds %struct.DataTy, ptr %D, i32 0, i32 1
%arrayidx = getelementptr inbounds [2 x float], ptr %b, i64 0, i64 0
%2 = getelementptr float, ptr %arrayidx, i32 1
%3 = ptrtoint ptr %2 to i64
%4 = ptrtoint ptr %a to i64
%5 = sub i64 %3, %4
%6 = sdiv exact i64 %5, ptrtoint (ptr getelementptr (i8, ptr null, i32
1) to i64)

Where %2 is wrong for (D.b[:2]) is pointer to first element of array
section. It should pointe to last element of array section.

The fix is to emit the pointer to the last element of array section and
use this pointer as the highest element in partial struct data.

After change IR:
%a = getelementptr inbounds %struct.DataTy, ptr %D, i32 0, i32 0
%b = getelementptr inbounds %struct.DataTy, ptr %D, i32 0, i32 1
%arrayidx = getelementptr inbounds [2 x float], ptr %b, i64 0, i64 0
%b1 = getelementptr inbounds %struct.DataTy, ptr %D, i32 0, i32 1
%arrayidx2 = getelementptr inbounds [2 x float], ptr %b1, i64 0, i64 1
%1 = getelementptr float, ptr %arrayidx2, i32 1
%2 = ptrtoint ptr %1 to i64
%3 = ptrtoint ptr %a to i64
%4 = sub i64 %2, %3
%5 = sdiv exact i64 %4, ptrtoint (ptr getelementptr (i8, ptr null, i32
1) to i64)

show more ...


Revision tags: llvmorg-17.0.6, llvmorg-17.0.5, llvmorg-17.0.4
# 84a3aadf 20-Oct-2023 Aaron Ballman <aaron@aaronballman.com>

Diagnose use of VLAs in C++ by default

Reapplication of 7339c0f782d5c70e0928f8991b0c05338a90c84c with a fix
for a crash involving arrays without a size expression.

Clang supports VLAs in C++ as an

Diagnose use of VLAs in C++ by default

Reapplication of 7339c0f782d5c70e0928f8991b0c05338a90c84c with a fix
for a crash involving arrays without a size expression.

Clang supports VLAs in C++ as an extension, but we currently only warn
on their use when you pass -Wvla, -Wvla-extension, or -pedantic.
However, VLAs as they're expressed in C have been considered by WG21
and rejected, are easy to use accidentally to the surprise of users
(e.g., https://ddanilov.me/default-non-standard-features/), and they
have potential security implications beyond constant-size arrays
(https://wiki.sei.cmu.edu/confluence/display/c/ARR32-C.+Ensure+size+arguments+for+variable+length+arrays+are+in+a+valid+range).
C++ users should strongly consider using other functionality such as
std::vector instead.

This seems like sufficiently compelling evidence to warn users about
VLA use by default in C++ modes. This patch enables the -Wvla-extension
diagnostic group in C++ language modes by default, and adds the warning
group to -Wall in GNU++ language modes. The warning is still opt-in in
C language modes, where support for VLAs is somewhat less surprising to
users.

RFC: https://discourse.llvm.org/t/rfc-diagnosing-use-of-vlas-in-c/73109
Fixes https://github.com/llvm/llvm-project/issues/62836
Differential Revision: https://reviews.llvm.org/D156565

show more ...


# f5043f46 20-Oct-2023 Aaron Ballman <aaron@aaronballman.com>

Revert "Diagnose use of VLAs in C++ by default"

This reverts commit 7339c0f782d5c70e0928f8991b0c05338a90c84c.

Breaks bots:
https://lab.llvm.org/buildbot/#/builders/139/builds/51875
https://lab.llvm

Revert "Diagnose use of VLAs in C++ by default"

This reverts commit 7339c0f782d5c70e0928f8991b0c05338a90c84c.

Breaks bots:
https://lab.llvm.org/buildbot/#/builders/139/builds/51875
https://lab.llvm.org/buildbot/#/builders/164/builds/45262

show more ...


# 7339c0f7 20-Oct-2023 Aaron Ballman <aaron@aaronballman.com>

Diagnose use of VLAs in C++ by default

Clang supports VLAs in C++ as an extension, but we currently only warn
on their use when you pass -Wvla, -Wvla-extension, or -pedantic.
However, VLAs as they'r

Diagnose use of VLAs in C++ by default

Clang supports VLAs in C++ as an extension, but we currently only warn
on their use when you pass -Wvla, -Wvla-extension, or -pedantic.
However, VLAs as they're expressed in C have been considered by WG21
and rejected, are easy to use accidentally to the surprise of users
(e.g., https://ddanilov.me/default-non-standard-features/), and they
have potential security implications beyond constant-size arrays
(https://wiki.sei.cmu.edu/confluence/display/c/ARR32-C.+Ensure+size+arguments+for+variable+length+arrays+are+in+a+valid+range).
C++ users should strongly consider using other functionality such as
std::vector instead.

This seems like sufficiently compelling evidence to warn users about
VLA use by default in C++ modes. This patch enables the -Wvla-extension
diagnostic group in C++ language modes by default, and adds the warning
group to -Wall in GNU++ language modes. The warning is still opt-in in
C language modes, where support for VLAs is somewhat less surprising to
users.

RFC: https://discourse.llvm.org/t/rfc-diagnosing-use-of-vlas-in-c/73109
Fixes https://github.com/llvm/llvm-project/issues/62836
Differential Revision: https://reviews.llvm.org/D156565

show more ...


Revision tags: llvmorg-17.0.3, 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, llvmorg-16.0.6
# 0c6f2f62 06-Jun-2023 Animesh Kumar <animesh.kumar@amd.com>

[OpenMP] Update the default version of OpenMP to 5.1

The default version of OpenMP is updated from 5.0 to 5.1 which means if -fopenmp is specified but -fopenmp-version is not specified with clang, t

[OpenMP] Update the default version of OpenMP to 5.1

The default version of OpenMP is updated from 5.0 to 5.1 which means if -fopenmp is specified but -fopenmp-version is not specified with clang, the default version of OpenMP is taken to be 5.1. After modifying the Frontend for that, various LIT tests were updated. This patch contains all such changes. At a high level, these are the patterns of changes observed in LIT tests -

# RUN lines which mentioned `-fopenmp-version=50` need to kept only if the IR for version 5.0 and 5.1 are different. Otherwise only one RUN line with no version info(i.e. default version) needs to be there.

# Test cases of this sort already had the RUN lines with respect to the older default version 5.0 and the version 5.1. Only swapping the version specification flag `-fopenmp-version` from newer version RUN line to older version RUN line is required.

# Diagnostics: Remove the 5.0 version specific RUN lines if there was no difference in the Diagnostics messages with respect to the default 5.1.

# Diagnostics: In case there was any difference in diagnostics messages between 5.0 and 5.1, mention version specific messages in tests.

# If the test contained version specific ifdef's e.g. "#ifdef OMP5" but there were no RUN lines for any other version than 5.X, then bring the code guarded by ifdef's outside and remove the ifdef's.

# Some tests had RUN lines for both 5.0 and 5.1 versions, but it is found that the IR for 5.0 is not different from the 5.1, therefore such RUN lines are redundant. So, such duplicated lines are removed.

# To generate CHECK lines automatically, use the script llvm/utils/update_cc_test_checks.py

Reviewed By: saiislam, ABataev

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

(cherry picked from commit 9dd2999907dc791136a75238a6000f69bf67cf4e)

show more ...


Revision tags: 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, llvmorg-15.0.3, working, llvmorg-15.0.2
# 0f8e7b43 30-Sep-2022 Animesh Kumar <animesh.kumar@amd.com>

[OpenMP] Add map clause to the LIT test on use_device_addr clause

As per the OpenMP Spec, "A list item in a use_device_addr clause
must have a corresponding list item in the device data environment"

[OpenMP] Add map clause to the LIT test on use_device_addr clause

As per the OpenMP Spec, "A list item in a use_device_addr clause
must have a corresponding list item in the device data environment"
. Therefore a `map` clause is added which will make sure that the
respective list items are mapped to the device data environment
before the `use_device_addr` clause is specified. The CHECK lines
are also modified based on this change.

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

show more ...


# 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: llvmorg-15.0.1, llvmorg-15.0.0, 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 ...


# a9656bd1 21-Mar-2022 Nikita Popov <npopov@redhat.com>

[CodeGen][OpenMP] Make EmitLoadOfPointer() type consistent

If necessary insert a bitcast beforehand, so the LLVM-level pointer
type and the Clang-level pointer type line up.


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, llvmorg-13.0.1-rc2, llvmorg-13.0.1-rc1, llvmorg-13.0.0, llvmorg-13.0.0-rc4, llvmorg-13.0.0-rc3, llvmorg-13.0.0-rc2, llvmorg-13.0.0-rc1, llvmorg-14-init
# d04d9220 01-Jul-2021 Alexey Bataev <a.bataev@outlook.com>

[OPENMP]Fix PR50347: Mapping of global scope deep object fails.

Changed the we handle llvm::Constants in sizes arrays. ConstExprs and
GlobalValues cannot be used as initializers, need to put them at

[OPENMP]Fix PR50347: Mapping of global scope deep object fails.

Changed the we handle llvm::Constants in sizes arrays. ConstExprs and
GlobalValues cannot be used as initializers, need to put them at the
runtime, otherwise there wight be the compilation errors.

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

show more ...


# ca6fa71b 24-Feb-2022 Alexey Bataev <a.bataev@outlook.com>

Revert "[OPENMP]Fix PR50347: Mapping of global scope deep object fails."

This reverts commit 638938117aeae5518d6cacd066ffd9830ef4fc9a. Need to
fix reported fail https://lab.llvm.org/buildbot/#/build

Revert "[OPENMP]Fix PR50347: Mapping of global scope deep object fails."

This reverts commit 638938117aeae5518d6cacd066ffd9830ef4fc9a. Need to
fix reported fail https://lab.llvm.org/buildbot/#/builders/193/builds/7496

show more ...


# 63893811 01-Jul-2021 Alexey Bataev <a.bataev@outlook.com>

[OPENMP]Fix PR50347: Mapping of global scope deep object fails.

Changed the we handle llvm::Constants in sizes arrays. ConstExprs and
GlobalValues cannot be used as initializers, need to put them at

[OPENMP]Fix PR50347: Mapping of global scope deep object fails.

Changed the we handle llvm::Constants in sizes arrays. ConstExprs and
GlobalValues cannot be used as initializers, need to put them at the
runtime, otherwise there wight be the compilation errors.

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

show more ...


Revision tags: llvmorg-12.0.1, llvmorg-12.0.1-rc4, llvmorg-12.0.1-rc3, llvmorg-12.0.1-rc2, llvmorg-12.0.1-rc1, llvmorg-12.0.0, llvmorg-12.0.0-rc5, llvmorg-12.0.0-rc4, llvmorg-12.0.0-rc3, llvmorg-12.0.0-rc2, llvmorg-11.1.0, llvmorg-11.1.0-rc3, llvmorg-12.0.0-rc1, llvmorg-13-init, llvmorg-11.1.0-rc2
# b272698d 19-Jan-2021 Alexey Bataev <a.bataev@hotmail.com>

[OPENMP]Do not use OMP_MAP_TARGET_PARAM for data movement directives.

OMP_MAP_TARGET_PARAM flag is used to mark the data that shoud be passed
as arguments to the target kernels, nothing else. But th

[OPENMP]Do not use OMP_MAP_TARGET_PARAM for data movement directives.

OMP_MAP_TARGET_PARAM flag is used to mark the data that shoud be passed
as arguments to the target kernels, nothing else. But the compiler still
marks the data with OMP_MAP_TARGET_PARAM flags even if the data is
passed to the data movement directives, like target data, target update
etc. This flag is just ignored for this directives and the compiler does
not need to emit it.

Reviewed By: cchen

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

show more ...


Revision tags: llvmorg-11.1.0-rc1, llvmorg-11.0.1, llvmorg-11.0.1-rc2, llvmorg-11.0.1-rc1
# da8bec47 19-Nov-2020 Joseph Huber <jhuber6@vols.utk.edu>

[OpenMP] Add Location Fields to Libomptarget Runtime for Debugging

Summary:
Add support for passing source locations to libomptarget runtime functions using the ident_t struct present in the rest of

[OpenMP] Add Location Fields to Libomptarget Runtime for Debugging

Summary:
Add support for passing source locations to libomptarget runtime functions using the ident_t struct present in the rest of the libomp API. This will allow the runtime system to give much more insightful error messages and debugging values.

Reviewers: jdoerfert grokos

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

show more ...


# 97e55cfe 13-Nov-2020 Joseph Huber <jhuber6@vols.utk.edu>

[OpenMP] Add Passing in Original Declaration Names To Mapper API

Summary:
This patch adds support for passing in the original delcaration name in the source file to the libomptarget runtime. This wi

[OpenMP] Add Passing in Original Declaration Names To Mapper API

Summary:
This patch adds support for passing in the original delcaration name in the source file to the libomptarget runtime. This will allow the runtime to provide more intelligent debugging messages. This patch takes the original expression parsed from the OpenMP map / update clause and provides a textual representation if it was explicitly mapped, otherwise it takes the name of the variable declaration as a fallback. The information in passed to the runtime in a global array of strings that matches the existing ident_t source location strings using ";name;filename;column;row;;"

Reviewers: jdoerfert

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

show more ...


# 207cf71f 28-Oct-2020 Benjamin Kramer <benny.kra@googlemail.com>

Revert "[OpenMP] Add Passing in Original Declaration Names To Mapper API"

This reverts commit d981c7b7581efc3ef378709042100e75da0185a0 and
a87d7b3d448a16e416d1980b9d6aea99e4c9900b. Test fails under

Revert "[OpenMP] Add Passing in Original Declaration Names To Mapper API"

This reverts commit d981c7b7581efc3ef378709042100e75da0185a0 and
a87d7b3d448a16e416d1980b9d6aea99e4c9900b. Test fails under msan.

show more ...


# a87d7b3d 22-Oct-2020 Joseph Huber <jhuber6@vols.utk.edu>

[OpenMP] Add Passing in Original Declaration Names To Mapper API

Summary:
This patch adds support for passing in the original delcaration name in the
source file to the libomptarget runtime. This wi

[OpenMP] Add Passing in Original Declaration Names To Mapper API

Summary:
This patch adds support for passing in the original delcaration name in the
source file to the libomptarget runtime. This will allow the runtime to provide
more intelligent debugging messages. This patch takes the original expression
parsed from the OpenMP map / update clause and provides a textual
representation if it was explicitly mapped, otherwise it takes the name of the
variable declaration as a fallback. The information in passed to the runtime in
a global array of strings that matches the existing ident_t source location
strings using ";name;filename;column;row;;". See
clang/test/OpenMP/target_map_names.cpp for an example of the generated output
for a given map clause.

Reviewers: jdoervert

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

show more ...


Revision tags: llvmorg-11.0.0, llvmorg-11.0.0-rc6, llvmorg-11.0.0-rc5, llvmorg-11.0.0-rc4, llvmorg-11.0.0-rc3, llvmorg-11.0.0-rc2, llvmorg-11.0.0-rc1
# 537b16e9 16-Jul-2020 George Rokos <georgios.rokos@intel.com>

[OpenMP 5.0] Codegen support to pass user-defined mapper functions to runtime

This patch implements the code generation to use OpenMP 5.0 declare mapper (a.k.a. user-defined mapper) constructs.
Patc

[OpenMP 5.0] Codegen support to pass user-defined mapper functions to runtime

This patch implements the code generation to use OpenMP 5.0 declare mapper (a.k.a. user-defined mapper) constructs.
Patch written by Lingda Li.

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

show more ...


Revision tags: llvmorg-12-init, llvmorg-10.0.1, llvmorg-10.0.1-rc4, llvmorg-10.0.1-rc3, llvmorg-10.0.1-rc2
# 90b54fa0 25-May-2020 Alexey Bataev <a.bataev@hotmail.com>

[OPENMP50]Codegen for use_device_addr clauses.

Summary:
Added codegen for use_device_addr clause. The components of the list
items are mapped as a kind of RETURN components and then the returned
bas

[OPENMP50]Codegen for use_device_addr clauses.

Summary:
Added codegen for use_device_addr clause. The components of the list
items are mapped as a kind of RETURN components and then the returned
base address is used instead of the real address of the base declaration
used in the use_device_addr expressions.

Reviewers: jdoerfert

Subscribers: yaxunl, guansong, sstefan1, cfe-commits, caomhin

Tags: #clang

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

show more ...