|
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 ...
|