Commit Graph

138 Commits

Author SHA1 Message Date
Petr Hosek 1e634f3952 Revert "Support for instrumenting only selected files or functions"
This reverts commit 4edf35f11a because
the test fails on Windows bots.
2021-01-26 12:25:28 -08:00
Petr Hosek 4edf35f11a 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
2021-01-26 11:11:39 -08:00
Alan Phipps 9f2967bcfe [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
2021-01-05 09:51:51 -06:00
Arthur Eubanks 5c31b8b94f Revert "Use uint64_t for branch weights instead of uint32_t"
This reverts commit 10f2a0d662.

More uint64_t overflows.
2020-10-31 00:25:32 -07:00
Arthur Eubanks 10f2a0d662 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
2020-10-30 10:03:46 -07:00
Nico Weber 2a4e704c92 Revert "Use uint64_t for branch weights instead of uint32_t"
This reverts commit e5766f25c6.
Makes clang assert when building Chromium, see https://crbug.com/1142813
for a repro.
2020-10-27 09:26:21 -04:00
Arthur Eubanks e5766f25c6 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
2020-10-26 20:24:04 -07:00
Mark de Wever 389c8d5b20 [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.
2020-10-18 18:50:21 +02:00
Michael Liao c7b683c126 [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
2020-08-10 11:01:46 -04:00
serge-sans-paille de02a75e39 [PGO] Fix computation of function Hash
And bump its version number accordingly.

This is a patched recommit of 7c298c104b

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
2020-05-27 09:15:21 +02:00
Benjamin Kramer 2b8d6fa0ac Revert "[PGO] Fix computation of function Hash"
This reverts commit 7c298c104b.
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
2020-05-25 20:14:28 +02:00
serge-sans-paille 7c298c104b [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
2020-05-25 17:17:29 +02:00
Hans Wennborg 55b9b11fea 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
2020-05-05 18:59:00 +02:00
Mark de Wever 8dc7b982b4 [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
2020-01-01 20:01:37 +01:00
Reid Kleckner 4c1a1d3cf9 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
2019-11-14 15:23:15 -08:00
Jonas Devlieghere 2b3d49b610 [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
2019-08-14 23:04:18 +00:00
Reid Kleckner f9ef9f868c [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
2019-02-26 20:42:52 +00:00
Chandler Carruth 2946cd7010 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
2019-01-19 08:50:56 +00:00
Sam McCall e60151c915 [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
2019-01-14 10:31:42 +00:00
Richard Smith 8baa50013c [cxx2a] P0614R1: Support init-statements in range-based for loops.
We don't yet support this for the case where a range-based for loop is
implicitly rewritten to an ObjC for..in statement.

llvm-svn: 343350
2018-09-28 18:44:09 +00:00
Stephen Kelly f2ceec4811 Port getLocStart -> getBeginLoc
Reviewers: teemperor!

Subscribers: jholewinski, whisperity, jfb, cfe-commits

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

llvm-svn: 339385
2018-08-09 21:08:08 +00:00
Adrian Prantl 9fc8faf9e6 Remove \brief commands from doxygen comments.
This is similar to the LLVM change https://reviews.llvm.org/D46290.

We've been running doxygen with the autobrief option for a couple of
years now. This makes the \brief markers into our comments
redundant. Since they are a visual distraction and we don't want to
encourage more \brief markers in new code either, this patch removes
them all.

Patch produced by

for i in $(git grep -l '\@brief'); do perl -pi -e 's/\@brief //g' $i & done
for i in $(git grep -l '\\brief'); do perl -pi -e 's/\\brief //g' $i & done

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

llvm-svn: 331834
2018-05-09 01:00:01 +00:00
Zachary Turner 8065f0b975 Mark all library options as hidden.
These command line options are not intended for public use, and often
don't even make sense in the context of a particular tool anyway. About
90% of them are already hidden, but when people add new options they
forget to hide them, so if you were to make a brand new tool today, link
against one of LLVM's libraries, and run tool -help you would get a
bunch of junk that doesn't make sense for the tool you're writing.

This patch hides these options. The real solution is to not have
libraries defining command line options, but that's a much larger effort
and not something I'm prepared to take on.

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

llvm-svn: 319505
2017-12-01 00:53:10 +00:00
Vedant Kumar 6186971a4a [PGO] Detect more structural changes with the stable hash
Lifting from Bob Wilson's notes: The hash value that we compute and
store in PGO profile data to detect out-of-date profiles does not
include enough information. This means that many significant changes to
the source will not cause compiler warnings about the profile being out
of date, and worse, we may continue to use the outdated profile data to
make bad optimization decisions.  There is some tension here because
some source changes won't affect PGO and we don't want to invalidate the
profile unnecessarily.

This patch adds a new hashing scheme which is more sensitive to loop
nesting, conditions, and out-of-order control flow. Here are examples
which show snippets which get the same hash under the current scheme,
and different hashes under the new scheme:

Loop Nesting Example
--------------------

  // Snippet 1
  while (foo()) {
    while (bar()) {}
  }

  // Snippet 2
  while (foo()) {}
  while (bar()) {}

Condition Example
-----------------

  // Snippet 1
  if (foo())
    bar();
  baz();

  // Snippet 2
  if (foo())
    bar();
  else
    baz();

Out-of-order Control Flow Example
---------------------------------

  // Snippet 1
  while (foo()) {
    if (bar()) {}
    baz();
  }

  // Snippet 2
  while (foo()) {
    if (bar())
      continue;
    baz();
  }

In each of these cases, it's useful to differentiate between the
snippets because swapping their profiles gives bad optimization hints.

The new hashing scheme considers some logical operators in an effort to
detect more changes in conditions. This isn't a perfect scheme. E.g, it
does not produce the same hash for these equivalent snippets:

  // Snippet 1
  bool c = !a || b;
  if (d && e) {}

  // Snippet 2
  bool f = d && e;
  bool c = !a || b;
  if (f) {}

This would require an expensive data flow analysis. Short of that, the
new hashing scheme looks reasonably complete, based on a scan over the
statements we place counters on.

Profiles which use the old version of the PGO hash remain valid and can
be used without issue (there are tests in tree which check this).

rdar://17068282

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

llvm-svn: 318229
2017-11-14 23:56:53 +00:00
Vedant Kumar 33d0a1ccd3 [Profile] Do not assign counters to functions without bodies
The root cause of the issues reported in D32406 and D34680 is that clang
instruments functions without bodies. Make it stop doing that, and also
teach it how to use old (incorrectly generated) profiles without
crashing.

llvm-svn: 306883
2017-06-30 21:02:14 +00:00
Vedant Kumar 9e32aa2587 Remove a dead field. NFC.
Suggested by Adam Folwarczny!

llvm-svn: 301250
2017-04-24 20:54:36 +00:00
Vedant Kumar bc370f0c18 [Coverage] Avoid null deref in skipRegionMappingForDecl (fixes PR32761)
Patch by Adam Folwarczny!

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

llvm-svn: 301249
2017-04-24 20:52:04 +00:00
Zachary Turner 82a0c97b32 Add a function to MD5 a file's contents.
In doing so, clean up the MD5 interface a little.  Most
existing users only care about the lower 8 bytes of an MD5,
but for some users that care about the upper and lower,
there wasn't a good interface.  Furthermore, consumers
of the MD5 checksum were required to handle endianness
details on their own, so it seems reasonable to abstract
this into a nicer interface that just gives you the right
value.

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

llvm-svn: 298322
2017-03-20 23:33:18 +00:00
Vedant Kumar 502bbfafca Retry: [profiling] Fix profile counter increment when emitting selects (PR32019)
2nd attempt: the first was in r296231, but it had a use after lifetime
bug.

Clang has logic to lower certain conditional expressions directly into llvm
select instructions. However, it does not emit the correct profile counter
increment as it does this: it emits an unconditional increment of the counter
for the 'then branch', even if the value selected is from the 'else branch'
(this is PR32019).

That means, given the following snippet, we would report that "0" is selected
twice, and that "1" is never selected:

  int f1(int x) {
    return x ? 0 : 1;
               ^2  ^0
  }

  f1(0);
  f1(1);

Fix the problem by using the instrprof_increment_step intrinsic to do the
proper increment.

llvm-svn: 296245
2017-02-25 06:35:45 +00:00
Vedant Kumar a45f315e2f Revert "[profiling] Fix profile counter increment when emitting selects (PR32019)"
This reverts commit r296231. It causes an assertion failure on 32-bit
machines

clang: /export/users/atombot/llvm/clang-atom-d525-fedora-rel/llvm/lib/IR/Instructions.cpp:263: void llvm::CallInst::init(llvm::FunctionType*, llvm::Value*, llvm::ArrayRef<llvm::Value*>, llvm::ArrayRef<llvm::OperandBundleDefT<llvm::Value*> >, const llvm::Twine&): Assertion `(i >= FTy->getNumParams() || FTy->getParamType(i) == Args[i]->getType()) && "Calling a function with a bad signature!"' failed.
llvm::sys::PrintStackTrace(llvm::raw_ostream&) (/export/users/atombot/llvm/clang-atom-d525-fedora-rel/stage1/./bin/clang+0x1c5fbfa)
llvm::sys::RunSignalHandlers() (/export/users/atombot/llvm/clang-atom-d525-fedora-rel/stage1/./bin/clang+0x1c5dc7e)
SignalHandler(int) (/export/users/atombot/llvm/clang-atom-d525-fedora-rel/stage1/./bin/clang+0x1c5dde2)
__restore_rt (/lib64/libpthread.so.0+0x3f1d00efa0)
__GI_raise /home/glibctest/rpmbuild/BUILD/glibc-2.17-c758a686/signal/../nptl/sysdeps/unix/sysv/linux/raise.c:56:0
__GI_abort /home/glibctest/rpmbuild/BUILD/glibc-2.17-c758a686/stdlib/abort.c:92:0
__assert_fail_base /home/glibctest/rpmbuild/BUILD/glibc-2.17-c758a686/assert/assert.c:92:0
(/lib64/libc.so.6+0x3f1c82e622)
llvm::CallInst::init(llvm::FunctionType*, llvm::Value*, llvm::ArrayRef<llvm::Value*>, llvm::ArrayRef<llvm::OperandBundleDefT<llvm::Value*> >, llvm::Twine const&) (/export/users/atombot/llvm/clang-atom-d525-fedora-rel/stage1/./bin/clang+0x1804e3a)
clang::CodeGen::CodeGenPGO::emitCounterIncrement(clang::CodeGen::CGBuilderTy&, clang::Stmt const*, llvm::Value*) (/export/users/atombot/llvm/clang-atom-d525-fedora-rel/stage1/./bin/clang+0x1ec7891)

llvm-svn: 296234
2017-02-25 02:59:47 +00:00
Vedant Kumar c416e99d42 [profiling] Fix profile counter increment when emitting selects (PR32019)
Clang has logic to lower certain conditional expressions directly into
llvm select instructions. However, it does not emit the correct profile
counter increment as it does this: it emits an unconditional increment
of the counter for the 'then branch', even if the value selected is from
the 'else branch' (this is PR32019).

That means, given the following snippet, we would report that "0" is
selected twice, and that "1" is never selected:

  int f1(int x) {
    return x ? 0 : 1;
               ^2  ^0
  }

  f1(0);
  f1(1);

Fix the problem by using the instrprof_increment_step intrinsic to do
the proper increment.

llvm-svn: 296231
2017-02-25 02:30:03 +00:00
Vedant Kumar 7f809b2fbd [profiling] PR31992: Don't skip interesting non-base constructors
Fix the fact that we don't assign profile counters to constructors in
classes with virtual bases, or constructors with variadic parameters.

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

llvm-svn: 296062
2017-02-24 01:15:19 +00:00
Vedant Kumar cab432d97d Reuse a local variable. NFC.
llvm-svn: 295527
2017-02-18 01:50:11 +00:00
Vedant Kumar 9d2a16b9b1 [Coverage] Support for C++17 if initializers
Differential Revision: https://reviews.llvm.org/D25572

llvm-svn: 284293
2016-10-14 23:38:16 +00:00
Vedant Kumar f2a6ec5521 [Coverage] Support for C++17 switch initializers
Differential Revision: https://reviews.llvm.org/D25539

llvm-svn: 284292
2016-10-14 23:38:13 +00:00
Vedant Kumar c468bb8b29 [Coverage] Move logic to skip decl's into a helper (NFC)
llvm-svn: 275120
2016-07-11 22:57:44 +00:00
Vedant Kumar fa2d595541 Reapply^3 "[ProfileData] (clang) Use Error in InstrProf and Coverage, NFC"
Sync up with "(llvm) Use Error in InstrProf and Coverage".

llvm-svn: 270021
2016-05-19 03:54:54 +00:00
Vedant Kumar da9513fc3c Revert "Reapply^2 "[ProfileData] (clang) Use Error in InstrProf and Coverage, NFC""
This reverts commit r269695. The llvm commit does not pass the MSVC bot.

llvm-svn: 269701
2016-05-16 21:04:19 +00:00
Vedant Kumar 3354e2c5fe Reapply^2 "[ProfileData] (clang) Use Error in InstrProf and Coverage, NFC"
Sync up with "(llvm) Use Error in InstrProf and Coverage".

Differential Revision: http://reviews.llvm.org/D19902

llvm-svn: 269695
2016-05-16 20:50:13 +00:00
Chandler Carruth 1b766d09d1 Revert "Reapply "[ProfileData] (clang) Use Error in InstrProf and Coverage, NFC""
This reverts commit r269492 as the corresponding LLVM commit was
reverted due to lots of warnings. See the review thread for the original
LLVM commit (r269491) for details.

llvm-svn: 269549
2016-05-14 05:39:45 +00:00
Vedant Kumar 0b7b7ae806 Reapply "[ProfileData] (clang) Use Error in InstrProf and Coverage, NFC"
Sync up with "(llvm) Use Error in InstrProf and Coverage".

Differential Revision: http://reviews.llvm.org/D19902

llvm-svn: 269492
2016-05-13 21:51:02 +00:00
Vedant Kumar 2d87639c5a Revert "[ProfileData] (clang) Use Error in InstrProf and Coverage, NFC"
This reverts commit r269463. It fails two llvm-profdata tests.

llvm-svn: 269468
2016-05-13 20:10:22 +00:00
Vedant Kumar 31af1fd161 [ProfileData] (clang) Use Error in InstrProf and Coverage, NFC
Sync up with "(llvm) Use Error in InstrProf and Coverage".

llvm-svn: 269463
2016-05-13 20:01:34 +00:00
Rong Xu f932f54254 PGO] PGOFuncName meta data if PGOFuncName is different from function's raw name
Write out the PGOFuncName meta data if PGOFuncName is different from function's
raw name. This should only apply to internal linkage functions. This is to be
consumed by indirect-call promotion when called in LTO optimization pass.

Differential Revision: http://reviews.llvm.org/D18624

llvm-svn: 267224
2016-04-22 21:19:05 +00:00
Betul Buyukkurt 3da993c419 [PGO] Avoid instrumenting constants at value sites
Value profiling should not profile constants and/or constant
expressions when they appear as callees in call instructions.
Constant expressions form when a direct callee has bitcasts or
inttoptr(ptrtint (callee)) nests surrounding it. Value profiling
should avoid instrumenting such cases. Mostly NFC.

llvm-svn: 265037
2016-03-31 18:41:34 +00:00
Betul Buyukkurt cb6f5f16e6 [PGO] Move the instrumentation point closer to the value site.
For terminator instructions, the value profiling instrumentation
happens in a basic block other than where the value site resides.
This CR moves the instrumentation point prior to the value site.
Mostly NFC.

llvm-svn: 264783
2016-03-29 20:44:09 +00:00
Richard Smith 01694c340d P0184R0: Allow types of 'begin' and 'end' expressions in range-based for loops to differ.
llvm-svn: 263895
2016-03-20 10:33:40 +00:00
Xinliang David Li 5527a9dd42 [PGO] code simplification: use existing VP annotation API /NFC
llvm-svn: 259819
2016-02-04 19:54:17 +00:00
Rong Xu 9837ef56b4 [PGO] cc1 option name change for profile instrumentation
This patch changes cc1 option -fprofile-instr-generate to an enum option
-fprofile-instrument={clang|none}. It also changes cc1 options
-fprofile-instr-generate= to -fprofile-instrument-path=.
The driver level option -fprofile-instr-generate and -fprofile-instr-generate=
remain intact. This change will pave the way to integrate new PGO
instrumentation in IR level.

Review: http://reviews.llvm.org/D16730
llvm-svn: 259811
2016-02-04 18:39:09 +00:00
Betul Buyukkurt 518276a5fe Clang changes for value profiling
Differential Revision: http://reviews.llvm.org/D8940

llvm-svn: 258650
2016-01-23 22:50:44 +00:00