#
52bcd691 |
| 23-Sep-2020 |
Yaxun (Sam) Liu <yaxun.liu@amd.com> |
Recommit "[CUDA][HIP] Defer overloading resolution diagnostics for host device functions"
This recommits 7f1f89ec8d9944559042bb6d3b1132eabe3409de and 40df06cdafc010002fc9cfe1dda73d689b7d27a6 with bu
Recommit "[CUDA][HIP] Defer overloading resolution diagnostics for host device functions"
This recommits 7f1f89ec8d9944559042bb6d3b1132eabe3409de and 40df06cdafc010002fc9cfe1dda73d689b7d27a6 with bug fixes for memory sanitizer failure and Tensile build failure.
show more ...
|
#
0628bea5 |
| 19-Oct-2020 |
Hans Wennborg <hans@chromium.org> |
Revert "[PM/CC1] Add -f[no-]split-cold-code CC1 option to toggle splitting"
This broke Chromium's PGO build, it seems because hot-cold-splitting got turned on unintentionally. See comment on the cod
Revert "[PM/CC1] Add -f[no-]split-cold-code CC1 option to toggle splitting"
This broke Chromium's PGO build, it seems because hot-cold-splitting got turned on unintentionally. See comment on the code review for repro etc.
> This patch adds -f[no-]split-cold-code CC1 options to clang. This allows > the splitting pass to be toggled on/off. The current method of passing > `-mllvm -hot-cold-split=true` to clang isn't ideal as it may not compose > correctly (say, with `-O0` or `-Oz`). > > To implement the -fsplit-cold-code option, an attribute is applied to > functions to indicate that they may be considered for splitting. This > removes some complexity from the old/new PM pipeline builders, and > behaves as expected when LTO is enabled. > > Co-authored by: Saleem Abdulrasool <compnerd@compnerd.org> > Differential Revision: https://reviews.llvm.org/D57265 > Reviewed By: Aditya Kumar, Vedant Kumar > Reviewers: Teresa Johnson, Aditya Kumar, Fedor Sergeev, Philip Pfaffe, Vedant Kumar
This reverts commit 273c299d5d649a0222fbde03c9a41e41913751b4.
show more ...
|
#
273c299d |
| 13-Oct-2020 |
Vedant Kumar <vsk@apple.com> |
[PM/CC1] Add -f[no-]split-cold-code CC1 option to toggle splitting
This patch adds -f[no-]split-cold-code CC1 options to clang. This allows the splitting pass to be toggled on/off. The current metho
[PM/CC1] Add -f[no-]split-cold-code CC1 option to toggle splitting
This patch adds -f[no-]split-cold-code CC1 options to clang. This allows the splitting pass to be toggled on/off. The current method of passing `-mllvm -hot-cold-split=true` to clang isn't ideal as it may not compose correctly (say, with `-O0` or `-Oz`).
To implement the -fsplit-cold-code option, an attribute is applied to functions to indicate that they may be considered for splitting. This removes some complexity from the old/new PM pipeline builders, and behaves as expected when LTO is enabled.
Co-authored by: Saleem Abdulrasool <compnerd@compnerd.org> Differential Revision: https://reviews.llvm.org/D57265 Reviewed By: Aditya Kumar, Vedant Kumar Reviewers: Teresa Johnson, Aditya Kumar, Fedor Sergeev, Philip Pfaffe, Vedant Kumar
show more ...
|
#
79829a47 |
| 15-Oct-2020 |
Leonard Chan <leonardchan@google.com> |
Revert "[clang] Add -fc++-abi= flag for specifying which C++ ABI to use"
This reverts commits 683b308c07bf827255fe1403056413f790e03729 and 8487bfd4e9ae186f9f588ef989d27a96cc2438c9.
We will go for a
Revert "[clang] Add -fc++-abi= flag for specifying which C++ ABI to use"
This reverts commits 683b308c07bf827255fe1403056413f790e03729 and 8487bfd4e9ae186f9f588ef989d27a96cc2438c9.
We will go for a more restricted approach that does not give freedom to everyone to change ABIs on whichever platform.
See the discussion on https://reviews.llvm.org/D85802.
show more ...
|
#
683b308c |
| 12-Aug-2020 |
Leonard Chan <leonardchan@google.com> |
[clang] Add -fc++-abi= flag for specifying which C++ ABI to use
This implements the flag proposed in RFC http://lists.llvm.org/pipermail/cfe-dev/2020-August/066437.html.
The goal is to add a way to
[clang] Add -fc++-abi= flag for specifying which C++ ABI to use
This implements the flag proposed in RFC http://lists.llvm.org/pipermail/cfe-dev/2020-August/066437.html.
The goal is to add a way to override the default target C++ ABI through a compiler flag. This makes it easier to test and transition between different C++ ABIs through compile flags rather than build flags.
In this patch: - Store `-fc++-abi=` in a LangOpt. This isn't stored in a CodeGenOpt because there are instances outside of codegen where Clang needs to know what the ABI is (particularly through ASTContext::createCXXABI), and we should be able to override the target default if the flag is provided at that point. - Expose the existing ABIs in TargetCXXABI as values that can be passed through this flag. - Create a .def file for these ABIs to make it easier to check flag values. - Add an error for diagnosing bad ABI flag values.
Differential Revision: https://reviews.llvm.org/D85802
show more ...
|
#
77bb3ebe |
| 13-Oct-2020 |
Artem Dergachev <artem.dergachev@gmail.com> |
Revert "[analyzer] NFC: Move path diagnostic consumer implementations to libAnalysis."
This reverts commit 44b7cf2983b6a8373c99a9b254f8c3f944e03f35.
|
#
44b7cf29 |
| 30-Jul-2020 |
Artem Dergachev <artem.dergachev@gmail.com> |
[analyzer] NFC: Move path diagnostic consumer implementations to libAnalysis.
With this change, we're more or less ready to allow users outside of the Static Analyzer to take advantage of path diagn
[analyzer] NFC: Move path diagnostic consumer implementations to libAnalysis.
With this change, we're more or less ready to allow users outside of the Static Analyzer to take advantage of path diagnostic consumers for emitting their warnings in different formats.
Differential Revision: https://reviews.llvm.org/D67422
show more ...
|
#
20898784 |
| 30-Sep-2020 |
Ties Stuij <ties.stuij@arm.com> |
[ARM] Follow AACPS standard for volatile bit-fields access width
This patch resumes the work of D16586. According to the AAPCS, volatile bit-fields should be accessed using containers of the widht o
[ARM] Follow AACPS standard for volatile bit-fields access width
This patch resumes the work of D16586. According to the AAPCS, volatile bit-fields should be accessed using containers of the widht of their declarative type. In such case: ``` struct S1 { short a : 1; } ``` should be accessed using load and stores of the width (sizeof(short)), where now the compiler does only load the minimum required width (char in this case). However, as discussed in D16586, that could overwrite non-volatile bit-fields, which conflicted with C and C++ object models by creating data race conditions that are not part of the bit-field, e.g. ``` struct S2 { short a; int b : 16; } ``` Accessing `S2.b` would also access `S2.a`.
The AAPCS Release 2020Q2 (https://documentation-service.arm.com/static/5efb7fbedbdee951c1ccf186?token=) section 8.1 Data Types, page 36, "Volatile bit-fields - preserving number and width of container accesses" has been updated to avoid conflict with the C++ Memory Model. Now it reads in the note: ``` This ABI does not place any restrictions on the access widths of bit-fields where the container overlaps with a non-bit-field member or where the container overlaps with any zero length bit-field placed between two other bit-fields. This is because the C/C++ memory model defines these as being separate memory locations, which can be accessed by two threads simultaneously. For this reason, compilers must be permitted to use a narrower memory access width (including splitting the access into multiple instructions) to avoid writing to a different memory location. For example, in struct S { int a:24; char b; }; a write to a must not also write to the location occupied by b, this requires at least two memory accesses in all current Arm architectures. In the same way, in struct S { int a:24; int:0; int b:8; };, writes to a or b must not overwrite each other. ```
I've updated the patch D16586 to follow such behavior by verifying that we only change volatile bit-field access when: - it won't overlap with any other non-bit-field member - we only access memory inside the bounds of the record - avoid overlapping zero-length bit-fields.
Regarding the number of memory accesses, that should be preserved, that will be implemented by D67399.
Reviewed By: ostannard
Differential Revision: https://reviews.llvm.org/D72932
show more ...
|
#
71d3b7ec |
| 09-Oct-2020 |
Anastasia Stulova <anastasia.stulova@arm.com> |
[OpenCL] Add new compilation mode for OpenCL 3.0.
Extended -cl-std/std flag with CL3.0 and added predefined version macros.
Patch by Anton Zabaznov (azabaznov)!
Tags: #clang
Differential Revision
[OpenCL] Add new compilation mode for OpenCL 3.0.
Extended -cl-std/std flag with CL3.0 and added predefined version macros.
Patch by Anton Zabaznov (azabaznov)!
Tags: #clang
Differential Revision: https://reviews.llvm.org/D88300
show more ...
|
#
92bca128 |
| 08-Oct-2020 |
diggerlin <digger.llvm@gmail.com> |
[AIX] add new option -mignore-xcoff-visibility
SUMMARY:
In IBM compiler xlclang , there is an option -fnovisibility which suppresses visibility. For more details see: https://www.ibm.com/support/kn
[AIX] add new option -mignore-xcoff-visibility
SUMMARY:
In IBM compiler xlclang , there is an option -fnovisibility which suppresses visibility. For more details see: https://www.ibm.com/support/knowledgecenter/SSGH3R_16.1.0/com.ibm.xlcpp161.aix.doc/compiler_ref/opt_visibility.html.
We need to add the option -mignore-xcoff-visibility for compatibility with the IBM AIX OS (as the option is enabled by default in AIX). With this option llvm does not emit any visibility attribute to ASM or XCOFF object file.
The option only work on the AIX OS, for other non-AIX OS using the option will report an unsupported options error.
In AIX OS:
1.1 the option -mignore-xcoff-visibility is enabled by default , if there is not -fvisibility=* and -mignore-xcoff-visibility explicitly in the clang command .
1.2 if there is -fvisibility=* explicitly but not -mignore-xcoff-visibility explicitly in the clang command. it will generate visibility attributes.
1.3 if there are both -fvisibility=* and -mignore-xcoff-visibility explicitly in the clang command. The option "-mignore-xcoff-visibility" wins , it do not emit the visibility attribute.
The option -mignore-xcoff-visibility has no effect on visibility attribute when compile with -emit-llvm option to generated LLVM IR.
Reviewer: daltenty,Jason Liu
Differential Revision: https://reviews.llvm.org/D87451
show more ...
|
#
6668e4cc |
| 07-Oct-2020 |
Joseph Huber <jhuber6@vols.utk.edu> |
[OpenMP] Add Error Handling for Conflicting Pointer Sizes for Target Offload
Summary: This patch adds an error to Clang that detects if OpenMP offloading is used between two architectures with incom
[OpenMP] Add Error Handling for Conflicting Pointer Sizes for Target Offload
Summary: This patch adds an error to Clang that detects if OpenMP offloading is used between two architectures with incompatible pointer sizes. This ensures that the data mapping can be done correctly and solves an issue in code generation generating the wrong size pointer.
Reviewer: jdoerfert
Subscribers: cfe-commits delcypher guansong llvm-commits sstefan1 yaxunl
Tags: #OpenMP #Clang
Differential Revision: https://reviews.llvm.org/D88594
show more ...
|
#
1dce692d |
| 05-Oct-2020 |
Joseph Huber <jhuber6@vols.utk.edu> |
Revert "[OpenMP] Add Error Handling for Conflicting Pointer Sizes for Target Offload"
Reverting because detecting architecture size doesn't work on all platforms.
This reverts commit eaf73293cb6b8d
Revert "[OpenMP] Add Error Handling for Conflicting Pointer Sizes for Target Offload"
Reverting because detecting architecture size doesn't work on all platforms.
This reverts commit eaf73293cb6b8d45dd85ffced57aea7ad4177754.
show more ...
|
#
eaf73293 |
| 04-Oct-2020 |
Joseph Huber <jhuber6@vols.utk.edu> |
[OpenMP] Add Error Handling for Conflicting Pointer Sizes for Target Offload
Summary: This patch adds an error to Clang that detects if OpenMP offloading is used between two architectures with incom
[OpenMP] Add Error Handling for Conflicting Pointer Sizes for Target Offload
Summary: This patch adds an error to Clang that detects if OpenMP offloading is used between two architectures with incompatible pointer sizes. This ensures that the data mapping can be done correctly and solves an issue in code generation generating the wrong size pointer. This patch adds a new lit substitution, %omp_powerpc_triple that, if the system is 32-bit or 64-bit, sets the powerpc triple accordingly. This was required to fix some OpenMP tests that automatically populated the target architecture.
Reviewers: jdoerfert
Subscribers: cfe-commits guansong sstefan1 yaxunl delcypher
Tags: OpenMP clang LLVM
Differential Revision: https://reviews.llvm.org/D88594
show more ...
|
#
bdc85292 |
| 30-Sep-2020 |
Joseph Huber <jhuber6@vols.utk.edu> |
Revert "[OpenMP] Add Error Handling for Conflicting Pointer Sizes for Target Offload"
Failing tests on Arm due to the tests automatically populating incomatible pointer width architectures. Revertin
Revert "[OpenMP] Add Error Handling for Conflicting Pointer Sizes for Target Offload"
Failing tests on Arm due to the tests automatically populating incomatible pointer width architectures. Reverting until the tests are updated. Failing tests:
OpenMP/distribute_parallel_for_num_threads_codegen.cpp OpenMP/distribute_parallel_for_if_codegen.cpp OpenMP/distribute_parallel_for_simd_if_codegen.cpp OpenMP/distribute_parallel_for_simd_num_threads_codegen.cpp OpenMP/target_teams_distribute_parallel_for_if_codegen.cpp OpenMP/target_teams_distribute_parallel_for_simd_if_codegen.cpp OpenMP/teams_distribute_parallel_for_if_codegen.cpp OpenMP/teams_distribute_parallel_for_simd_if_codegen.cpp
This reverts commit 9d2378b59150f6f1cb5c9cf42ea06b0bb57029a1.
show more ...
|
#
9d2378b5 |
| 30-Sep-2020 |
Joseph Huber <jhuber6@vols.utk.edu> |
[OpenMP] Add Error Handling for Conflicting Pointer Sizes for Target Offload
Summary: This patch adds an error to Clang that detects if OpenMP offloading is used between two architectures with incom
[OpenMP] Add Error Handling for Conflicting Pointer Sizes for Target Offload
Summary: This patch adds an error to Clang that detects if OpenMP offloading is used between two architectures with incompatible pointer sizes. This ensures that the data mapping can be done correctly and solves an issue in code generation generating the wrong size pointer.
Reviewer: jdoerfert
Subscribers:
Tags: #OpenMP #Clang
Differential Revision:
show more ...
|
#
3681be87 |
| 29-Sep-2020 |
Fangrui Song <i@maskray.me> |
Add -fprofile-update={atomic,prefer-atomic,single}
GCC 7 introduced -fprofile-update={atomic,prefer-atomic} (prefer-atomic is for best efforts (some targets do not support atomics)) to increment cou
Add -fprofile-update={atomic,prefer-atomic,single}
GCC 7 introduced -fprofile-update={atomic,prefer-atomic} (prefer-atomic is for best efforts (some targets do not support atomics)) to increment counters atomically, which is exactly what we have done with -fprofile-instr-generate (D50867) and -fprofile-arcs (b5ef137c11b1cc6ae839ee75b49233825772bdd0). This patch adds the option to clang to surface the internal options at driver level.
GCC 7 also turned on -fprofile-update=prefer-atomic when -pthread is specified, but it has performance regression (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89307). So we don't follow suit.
Differential Revision: https://reviews.llvm.org/D87737
show more ...
|
#
9263931f |
| 25-Aug-2020 |
Alexey Bader <alexey.bader@intel.com> |
[SYCL] Assume SYCL device functions are convergent
SYCL device compiler (similar to other SPMD compilers) assumes that functions are convergent by default to avoid invalid transformations. This attr
[SYCL] Assume SYCL device functions are convergent
SYCL device compiler (similar to other SPMD compilers) assumes that functions are convergent by default to avoid invalid transformations. This attribute can be removed if compiler can prove that function does not have convergent operations.
Reviewed By: Naghasan
Differential Revision: https://reviews.llvm.org/D87282
show more ...
|
#
6f7fbdd2 |
| 18-Sep-2020 |
Ian Levesque <ianlevesque@fb.com> |
[xray] Function coverage groups
Add the ability to selectively instrument a subset of functions by dividing the functions into N logical groups and then selecting a group to cover. By selecting diff
[xray] Function coverage groups
Add the ability to selectively instrument a subset of functions by dividing the functions into N logical groups and then selecting a group to cover. By selecting different groups over time you could cover the entire application incrementally with lower overhead than instrumenting the entire application at once.
Differential Revision: https://reviews.llvm.org/D87953
show more ...
|
#
3453b692 |
| 24-Sep-2020 |
Reid Kleckner <rnk@google.com> |
Revert "Recommit "[CUDA][HIP] Defer overloading resolution diagnostics for host device functions""
This reverts commit e39da8ab6a286ac777d5fe7799f1eb782cf99938.
This depends on a change that needs
Revert "Recommit "[CUDA][HIP] Defer overloading resolution diagnostics for host device functions""
This reverts commit e39da8ab6a286ac777d5fe7799f1eb782cf99938.
This depends on a change that needs additional design review and needs to be reverted.
show more ...
|
#
e39da8ab |
| 23-Sep-2020 |
Yaxun (Sam) Liu <yaxun.liu@amd.com> |
Recommit "[CUDA][HIP] Defer overloading resolution diagnostics for host device functions"
This recommits 7f1f89ec8d9944559042bb6d3b1132eabe3409de and 40df06cdafc010002fc9cfe1dda73d689b7d27a6 after f
Recommit "[CUDA][HIP] Defer overloading resolution diagnostics for host device functions"
This recommits 7f1f89ec8d9944559042bb6d3b1132eabe3409de and 40df06cdafc010002fc9cfe1dda73d689b7d27a6 after fixing memory sanitizer failure.
show more ...
|
#
772bd8a7 |
| 17-Sep-2020 |
Yaxun (Sam) Liu <yaxun.liu@amd.com> |
Revert "[CUDA][HIP] Defer overloading resolution diagnostics for host device functions"
This reverts commit 7f1f89ec8d9944559042bb6d3b1132eabe3409de.
This reverts commit 40df06cdafc010002fc9cfe1dda
Revert "[CUDA][HIP] Defer overloading resolution diagnostics for host device functions"
This reverts commit 7f1f89ec8d9944559042bb6d3b1132eabe3409de.
This reverts commit 40df06cdafc010002fc9cfe1dda73d689b7d27a6.
show more ...
|
#
40df06cd |
| 16-Sep-2020 |
Yaxun (Sam) Liu <yaxun.liu@amd.com> |
[CUDA][HIP] Defer overloading resolution diagnostics for host device functions
In CUDA/HIP a function may become implicit host device function by pragma or constexpr. A host device function is check
[CUDA][HIP] Defer overloading resolution diagnostics for host device functions
In CUDA/HIP a function may become implicit host device function by pragma or constexpr. A host device function is checked in both host and device compilation. However it may be emitted only on host or device side, therefore the diagnostics should be deferred until it is known to be emitted.
Currently clang is only able to defer certain diagnostics. This causes false alarms and limits the usefulness of host device functions.
This patch lets clang defer all overloading resolution diagnostics for host device functions.
An option -fgpu-defer-diag is added to control this behavior. By default it is off.
It is NFC for other languages.
Differential Revision: https://reviews.llvm.org/D84364
show more ...
|
#
f1a3ab90 |
| 02-Sep-2020 |
Snehasish Kumar <snehasishk@google.com> |
[clang] Add a command line flag for the Machine Function Splitter.
This patch adds a command line flag for the machine function splitter (added in rG94faadaca4e1).
-fsplit-machine-functions Split m
[clang] Add a command line flag for the Machine Function Splitter.
This patch adds a command line flag for the machine function splitter (added in rG94faadaca4e1).
-fsplit-machine-functions Split machine functions using profile information (x86 ELF). On other targets an error is emitted. If profile information is not provided a warning is emitted notifying the user that profile information is required.
Differential Revision: https://reviews.llvm.org/D87047
show more ...
|
#
226d80eb |
| 14-Sep-2020 |
Teresa Johnson <tejohnson@google.com> |
[MemProf] Rename HeapProfiler to MemProfiler for consistency
This is consistent with the clang option added in 7ed8124d46f94601d5f1364becee9cee8538265e, and the comments on the runtime patch in D871
[MemProf] Rename HeapProfiler to MemProfiler for consistency
This is consistent with the clang option added in 7ed8124d46f94601d5f1364becee9cee8538265e, and the comments on the runtime patch in D87120.
Differential Revision: https://reviews.llvm.org/D87622
show more ...
|
#
a874d633 |
| 12-Sep-2020 |
Florian Hahn <flo@fhahn.com> |
[Clang] Add option to allow marking pass-by-value args as noalias.
After the recent discussion on cfe-dev 'Can indirect class parameters be noalias?' [1], it seems like using using noalias is proble
[Clang] Add option to allow marking pass-by-value args as noalias.
After the recent discussion on cfe-dev 'Can indirect class parameters be noalias?' [1], it seems like using using noalias is problematic for current C++, but should be allowed for C-only code.
This patch introduces a new option to let the user indicate that it is safe to mark indirect class parameters as noalias. Note that this also applies to external callers, e.g. it might not be safe to use this flag for C functions that are called by C++ functions.
In targets that allocate indirect arguments in the called function, this enables more agressive optimizations with respect to memory operations and brings a ~1% - 2% codesize reduction for some programs.
[1] : http://lists.llvm.org/pipermail/cfe-dev/2020-July/066353.html
Reviewed By: rjmccall
Differential Revision: https://reviews.llvm.org/D85473
show more ...
|