|
Revision tags: llvmorg-20.1.0, llvmorg-20.1.0-rc3, llvmorg-20.1.0-rc2, llvmorg-20.1.0-rc1, 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, 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, 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, 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, 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, llvmorg-15.0.2, 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 |
|
| #
d86a206f |
| 05-Jun-2022 |
Fangrui Song <[email protected]> |
Remove unneeded cl::ZeroOrMore for cl::opt/cl::list options
|
|
Revision tags: llvmorg-14.0.4, llvmorg-14.0.3, llvmorg-14.0.2, llvmorg-14.0.1, 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 |
|
| #
d677a7cb |
| 02-Jan-2022 |
Kazu Hirata <[email protected]> |
[clang] Remove redundant member initialization (NFC)
Identified with readability-redundant-member-init.
|
|
Revision tags: llvmorg-13.0.1-rc1 |
|
| #
424733c1 |
| 05-Oct-2021 |
Corentin Jabot <[email protected]> |
Implement if consteval (P1938)
Modify the IfStmt node to suppoort constant evaluated expressions.
Add a new ExpressionEvaluationContext::ImmediateFunctionContext to keep track of immediate function
Implement if consteval (P1938)
Modify the IfStmt node to suppoort constant evaluated expressions.
Add a new ExpressionEvaluationContext::ImmediateFunctionContext to keep track of immediate function contexts.
This proved easier/better/probably more efficient than walking the AST backward as it allows diagnosing nested if consteval statements.
show more ...
|
|
Revision tags: 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, llvmorg-12.0.1, llvmorg-12.0.1-rc4, llvmorg-12.0.1-rc3, llvmorg-12.0.1-rc2, llvmorg-12.0.1-rc1 |
|
| #
8f20ac95 |
| 13-May-2021 |
Reid Kleckner <[email protected]> |
[PGO] Don't reference functions unless value profiling is enabled
This reduces the size of chrome.dll.pdb built with optimizations, coverage, and line table info from 4,690,210,816 to 2,181,128,192,
[PGO] Don't reference functions unless value profiling is enabled
This reduces the size of chrome.dll.pdb built with optimizations, coverage, and line table info from 4,690,210,816 to 2,181,128,192, which makes it possible to fit under the 4GB limit.
This change can greatly reduce binary size in coverage builds, which do not need value profiling. IR PGO builds are unaffected. There is a minor behavior change for frontend PGO.
PGO and coverage both use InstrProfiling to create profile data with counters. PGO records the address of each function in the __profd_ global. It is used later to map runtime function pointer values back to source-level function names. Coverage does not appear to use this information.
Recording the address of every function with code coverage drastically increases code size. Consider this program:
void foo(); void bar(); inline void inlineMe(int x) { if (x > 0) foo(); else bar(); } int getVal(); int main() { inlineMe(getVal()); }
With code coverage, the InstrProfiling pass runs before inlining, and it captures the address of inlineMe in the __profd_ global. This greatly increases code size, because now the compiler can no longer delete trivial code.
One downside to this approach is that users of frontend PGO must apply the -mllvm -enable-value-profiling flag globally in TUs that enable PGO. Otherwise, some inline virtual method addresses may not be recorded and will not be able to be promoted. My assumption is that this mllvm flag is not popular, and most frontend PGO users don't enable it.
Differential Revision: https://reviews.llvm.org/D102818
show more ...
|
|
Revision tags: llvmorg-12.0.0, llvmorg-12.0.0-rc5, llvmorg-12.0.0-rc4, llvmorg-12.0.0-rc3, llvmorg-12.0.0-rc2 |
|
| #
9fd9b5a9 |
| 04-Feb-2021 |
Petr Hosek <[email protected]> |
Don't emit coverage mapping for excluded functions
When a function or a file is excluded using -fprofile-list= option, don't emit coverage mapping as doing so confuses users since those functions wo
Don't emit coverage mapping for excluded functions
When a function or a file is excluded using -fprofile-list= option, don't emit coverage mapping as doing so confuses users since those functions would always have zero count. This also reduces the binary size considerably in cases where only a few functions or files are being instrumented.
Differential Revision: https://reviews.llvm.org/D96000
show more ...
|
|
Revision tags: llvmorg-11.1.0, llvmorg-11.1.0-rc3, llvmorg-12.0.0-rc1, llvmorg-13-init, llvmorg-11.1.0-rc2 |
|
| #
bb9eb198 |
| 15-Jan-2021 |
Petr Hosek <[email protected]> |
Support for instrumenting only selected files or functions
This change implements support for applying profile instrumentation only to selected files or functions. The implementation uses the saniti
Support for instrumenting only selected files or functions
This change implements support for applying profile instrumentation only to selected files or functions. The implementation uses the sanitizer special case list format to select which files and functions to instrument, and relies on the new noprofile IR attribute to exclude functions from instrumentation.
Differential Revision: https://reviews.llvm.org/D94820
show more ...
|
| #
1e634f39 |
| 26-Jan-2021 |
Petr Hosek <[email protected]> |
Revert "Support for instrumenting only selected files or functions"
This reverts commit 4edf35f11a9e20bd5df3cb47283715f0ff38b751 because the test fails on Windows bots.
|
| #
4edf35f1 |
| 15-Jan-2021 |
Petr Hosek <[email protected]> |
Support for instrumenting only selected files or functions
This change implements support for applying profile instrumentation only to selected files or functions. The implementation uses the saniti
Support for instrumenting only selected files or functions
This change implements support for applying profile instrumentation only to selected files or functions. The implementation uses the sanitizer special case list format to select which files and functions to instrument, and relies on the new noprofile IR attribute to exclude functions from instrumentation.
Differential Revision: https://reviews.llvm.org/D94820
show more ...
|
|
Revision tags: llvmorg-11.1.0-rc1 |
|
| #
9f2967bc |
| 28-Dec-2020 |
Alan Phipps <[email protected]> |
[Coverage] Add support for Branch Coverage in LLVM Source-Based Code Coverage
This is an enhancement to LLVM Source-Based Code Coverage in clang to track how many times individual branch-generating
[Coverage] Add support for Branch Coverage in LLVM Source-Based Code Coverage
This is an enhancement to LLVM Source-Based Code Coverage in clang to track how many times individual branch-generating conditions are taken (evaluate to TRUE) and not taken (evaluate to FALSE). Individual conditions may comprise larger boolean expressions using boolean logical operators. This functionality is very similar to what is supported by GCOV except that it is very closely anchored to the ASTs.
Differential Revision: https://reviews.llvm.org/D84467
show more ...
|
|
Revision tags: llvmorg-11.0.1, llvmorg-11.0.1-rc2, llvmorg-11.0.1-rc1 |
|
| #
5c31b8b9 |
| 31-Oct-2020 |
Arthur Eubanks <[email protected]> |
Revert "Use uint64_t for branch weights instead of uint32_t"
This reverts commit 10f2a0d662d8d72eaac48d3e9b31ca8dc90df5a4.
More uint64_t overflows.
|
|
Revision tags: llvmorg-11.0.0, llvmorg-11.0.0-rc6 |
|
| #
10f2a0d6 |
| 30-Sep-2020 |
Arthur Eubanks <[email protected]> |
Use uint64_t for branch weights instead of uint32_t
CallInst::updateProfWeight() creates branch_weights with i64 instead of i32. To be more consistent everywhere and remove lots of casts from uint64
Use uint64_t for branch weights instead of uint32_t
CallInst::updateProfWeight() creates branch_weights with i64 instead of i32. To be more consistent everywhere and remove lots of casts from uint64_t to uint32_t, use i64 for branch_weights.
Reviewed By: davidxl
Differential Revision: https://reviews.llvm.org/D88609
show more ...
|
| #
2a4e704c |
| 27-Oct-2020 |
Nico Weber <[email protected]> |
Revert "Use uint64_t for branch weights instead of uint32_t"
This reverts commit e5766f25c62c185632e3a75bf45b313eadab774b. Makes clang assert when building Chromium, see https://crbug.com/1142813 fo
Revert "Use uint64_t for branch weights instead of uint32_t"
This reverts commit e5766f25c62c185632e3a75bf45b313eadab774b. Makes clang assert when building Chromium, see https://crbug.com/1142813 for a repro.
show more ...
|
| #
e5766f25 |
| 30-Sep-2020 |
Arthur Eubanks <[email protected]> |
Use uint64_t for branch weights instead of uint32_t
CallInst::updateProfWeight() creates branch_weights with i64 instead of i32. To be more consistent everywhere and remove lots of casts from uint64
Use uint64_t for branch weights instead of uint32_t
CallInst::updateProfWeight() creates branch_weights with i64 instead of i32. To be more consistent everywhere and remove lots of casts from uint64_t to uint32_t, use i64 for branch_weights.
Reviewed By: davidxl
Differential Revision: https://reviews.llvm.org/D88609
show more ...
|
| #
389c8d5b |
| 18-Oct-2020 |
Mark de Wever <[email protected]> |
[NFC] Make non-modifying members const.
Implementing the likelihood attributes for the iteration statements adds a new helper function. This function can't be const qualified since these non-modifyi
[NFC] Make non-modifying members const.
Implementing the likelihood attributes for the iteration statements adds a new helper function. This function can't be const qualified since these non-modifying members aren't const qualified.
show more ...
|
|
Revision tags: llvmorg-11.0.0-rc5, llvmorg-11.0.0-rc4, llvmorg-11.0.0-rc3, llvmorg-11.0.0-rc2 |
|
| #
c7b683c1 |
| 04-Aug-2020 |
Michael Liao <[email protected]> |
[PGO][CUDA][HIP] Skip generating profile on the device stub and wrong-side functions.
- Skip generating profile data on `__global__` function in the host compilation. It's a host-side stub functio
[PGO][CUDA][HIP] Skip generating profile on the device stub and wrong-side functions.
- Skip generating profile data on `__global__` function in the host compilation. It's a host-side stub function only and don't have profile instrumentation generated on the real function body. The extra profile data results in the malformed instrumentation profile data. - Skip generating region mapping on functions in the wrong-side, i.e., + For the device compilation, skip host-only functions; and, + For the host compilation, skip device-only functions (including `__global__` functions.) - As the device-side profiling is not ready yet, only host-side profile code generation is checked.
Differential Revision: https://reviews.llvm.org/D85276
show more ...
|
|
Revision tags: llvmorg-11.0.0-rc1, llvmorg-12-init, llvmorg-10.0.1, llvmorg-10.0.1-rc4, llvmorg-10.0.1-rc3, llvmorg-10.0.1-rc2 |
|
| #
de02a75e |
| 25-May-2020 |
serge-sans-paille <[email protected]> |
[PGO] Fix computation of function Hash
And bump its version number accordingly.
This is a patched recommit of 7c298c104bfe725d4315926a656263e8a5ac3054
Previous hash implementation was incorrectly
[PGO] Fix computation of function Hash
And bump its version number accordingly.
This is a patched recommit of 7c298c104bfe725d4315926a656263e8a5ac3054
Previous hash implementation was incorrectly passing an uint64_t, that got converted to an uint8_t, to finalize the hash computation. This led to different functions having the same hash if they only differ by the remaining statements, which is incorrect.
Added a new test case that trivially tests that a small function change is reflected in the hash value.
Not that as this patch fixes the hash computation, it would invalidate all hashes computed before that patch applies, this is why we bumped the version number.
Update profile data hash entries due to hash function update, except for binary version, in which case we keep the buggy behavior for backward compatibility.
Differential Revision: https://reviews.llvm.org/D79961
show more ...
|
| #
2b8d6fa0 |
| 25-May-2020 |
Benjamin Kramer <[email protected]> |
Revert "[PGO] Fix computation of function Hash"
This reverts commit 7c298c104bfe725d4315926a656263e8a5ac3054. Fails make check-clang.
Failing Tests (8): Clang :: Profile/c-counter-overflows.c Cla
Revert "[PGO] Fix computation of function Hash"
This reverts commit 7c298c104bfe725d4315926a656263e8a5ac3054. Fails make check-clang.
Failing Tests (8): Clang :: Profile/c-counter-overflows.c Clang :: Profile/c-general.c Clang :: Profile/c-unprofiled-blocks.c Clang :: Profile/cxx-rangefor.cpp Clang :: Profile/cxx-throws.cpp Clang :: Profile/misexpect-switch-default.c Clang :: Profile/misexpect-switch-nonconst.c Clang :: Profile/misexpect-switch.c
show more ...
|
|
Revision tags: llvmorg-10.0.1-rc1 |
|
| #
7c298c10 |
| 14-May-2020 |
serge-sans-paille <[email protected]> |
[PGO] Fix computation of function Hash
Previous implementation was incorrectly passing an uint64_t, that got converted to an uint8_t, to finalize the hash computation. This led to different function
[PGO] Fix computation of function Hash
Previous implementation was incorrectly passing an uint64_t, that got converted to an uint8_t, to finalize the hash computation. This led to different functions having the same hash if they only differ by the remaining statements, which is incorrect.
Added a new test case that trivially tests that a small function change is reflected in the hash value.
Not that as this patch fixes the hash computation, it invalidates all hashes computed before that patch applies, which could be an issue for large build system that pre-compute the profile data and let client download them as part of the build process.
Differential Revision: https://reviews.llvm.org/D79961
show more ...
|
| #
55b9b11f |
| 05-May-2020 |
Hans Wennborg <[email protected]> |
Don't assert about missing profile info in createProfileWeightsForLoop
The compiler shouldn't crash if the profile info is slightly off. We hit this in Chromium.
Differential revision: https://revi
Don't assert about missing profile info in createProfileWeightsForLoop
The compiler shouldn't crash if the profile info is slightly off. We hit this in Chromium.
Differential revision: https://reviews.llvm.org/D79417
show more ...
|
|
Revision tags: llvmorg-10.0.0, llvmorg-10.0.0-rc6, llvmorg-10.0.0-rc5, llvmorg-10.0.0-rc4, llvmorg-10.0.0-rc3, llvmorg-10.0.0-rc2, llvmorg-10.0.0-rc1, llvmorg-11-init |
|
| #
8dc7b982 |
| 01-Jan-2020 |
Mark de Wever <[email protected]> |
[NFC] Fixes -Wrange-loop-analysis warnings
This avoids new warnings due to D68912 adds -Wrange-loop-analysis to -Wall.
Differential Revision: https://reviews.llvm.org/D71857
|
|
Revision tags: llvmorg-9.0.1, llvmorg-9.0.1-rc3, llvmorg-9.0.1-rc2, llvmorg-9.0.1-rc1 |
|
| #
4c1a1d3c |
| 14-Nov-2019 |
Reid Kleckner <[email protected]> |
Add missing includes needed to prune LLVMContext.h include, NFC
These are a pre-requisite to removing #include "llvm/Support/Options.h" from LLVMContext.h: https://reviews.llvm.org/D70280
|
|
Revision tags: llvmorg-9.0.0, llvmorg-9.0.0-rc6, llvmorg-9.0.0-rc5, llvmorg-9.0.0-rc4, llvmorg-9.0.0-rc3 |
|
| #
2b3d49b6 |
| 14-Aug-2019 |
Jonas Devlieghere <[email protected]> |
[Clang] Migrate llvm::make_unique to std::make_unique
Now that we've moved to C++14, we no longer need the llvm::make_unique implementation from STLExtras.h. This patch is a mechanical replacement o
[Clang] Migrate llvm::make_unique to std::make_unique
Now that we've moved to C++14, we no longer need the llvm::make_unique implementation from STLExtras.h. This patch is a mechanical replacement of (hopefully) all the llvm::make_unique instances across the monorepo.
Differential revision: https://reviews.llvm.org/D66259
llvm-svn: 368942
show more ...
|
|
Revision tags: llvmorg-9.0.0-rc2, llvmorg-9.0.0-rc1, llvmorg-10-init, llvmorg-8.0.1, llvmorg-8.0.1-rc4, llvmorg-8.0.1-rc3, llvmorg-8.0.1-rc2, llvmorg-8.0.1-rc1, llvmorg-8.0.0, llvmorg-8.0.0-rc5, llvmorg-8.0.0-rc4, llvmorg-8.0.0-rc3 |
|
| #
f9ef9f86 |
| 26-Feb-2019 |
Reid Kleckner <[email protected]> |
[MS] Don't emit coverage for deleting dtors
Summary: The MS C++ ABI has no constructor variants, but it has destructor variants, so we should move the deleting destructor variant check outside the c
[MS] Don't emit coverage for deleting dtors
Summary: The MS C++ ABI has no constructor variants, but it has destructor variants, so we should move the deleting destructor variant check outside the check for "does the ABI have constructor variants".
Fixes PR37561, so basic code coverage works on Windows with C++.
Reviewers: vsk
Subscribers: jdoerfert, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D58691
llvm-svn: 354924
show more ...
|
|
Revision tags: llvmorg-7.1.0, llvmorg-7.1.0-rc1, llvmorg-8.0.0-rc2, llvmorg-8.0.0-rc1 |
|
| #
2946cd70 |
| 19-Jan-2019 |
Chandler Carruth <[email protected]> |
Update the file headers across all of the LLVM projects in the monorepo to reflect the new license.
We understand that people may be surprised that we're moving the header entirely to discuss the ne
Update the file headers across all of the LLVM projects in the monorepo to reflect the new license.
We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach.
Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository.
llvm-svn: 351636
show more ...
|
| #
e60151c9 |
| 14-Jan-2019 |
Sam McCall <[email protected]> |
[AST] RecursiveASTVisitor visits lambda classes when implicit visitation is on.
Summary: This fixes ASTContext's parent map for nodes in such classes (e.g. operator()). https://bugs.llvm.org/show_bu
[AST] RecursiveASTVisitor visits lambda classes when implicit visitation is on.
Summary: This fixes ASTContext's parent map for nodes in such classes (e.g. operator()). https://bugs.llvm.org/show_bug.cgi?id=39949
This also changes the observed shape of the AST for implicit RAVs. - this includes AST MatchFinder: cxxRecordDecl() now matches lambda classes, functionDecl() matches the call operator, and the parent chain is body -> call operator -> lambda class -> lambdaexpr rather than body -> lambdaexpr. - this appears not to matter for the ASTImporterLookupTable builder - this doesn't matter for the other RAVs in-tree.
In order to do this, we remove the TraverseLambdaBody hook. The problem is it's hard/weird to ensure this hook is called when traversing via the implicit class. There were just two users of this hook in-tree, who use it to skip bodies. I replaced these with explicitly traversing the captures only. Another approach would be recording the bodies when the lambda is visited, and then recognizing them later. I'd be open to suggestion on how to preserve this hook, instead.
Reviewers: aaron.ballman, JonasToth
Subscribers: cfe-commits, rsmith, jdennett
Differential Revision: https://reviews.llvm.org/D56444
llvm-svn: 351047
show more ...
|