summaryrefslogtreecommitdiffstats
path: root/clang/lib/CodeGen/CodeGenPGO.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Mark all library options as hidden.Zachary Turner2017-12-011-3/+4
| | | | | | | | | | | | | | | | | 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
* [PGO] Detect more structural changes with the stable hashVedant Kumar2017-11-141-13/+153
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [Profile] Do not assign counters to functions without bodiesVedant Kumar2017-06-301-0/+3
| | | | | | | | | 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
* Remove a dead field. NFC.Vedant Kumar2017-04-241-3/+0
| | | | | | Suggested by Adam Folwarczny! llvm-svn: 301250
* [Coverage] Avoid null deref in skipRegionMappingForDecl (fixes PR32761)Vedant Kumar2017-04-241-0/+3
| | | | | | | | Patch by Adam Folwarczny! Differential Revision: https://reviews.llvm.org/D32406 llvm-svn: 301249
* Add a function to MD5 a file's contents.Zachary Turner2017-03-201-1/+1
| | | | | | | | | | | | | | | 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
* Retry: [profiling] Fix profile counter increment when emitting selects (PR32019)Vedant Kumar2017-02-251-6/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Revert "[profiling] Fix profile counter increment when emitting selects ↵Vedant Kumar2017-02-251-13/+6
| | | | | | | | | | | | | | | | | | | | | (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
* [profiling] Fix profile counter increment when emitting selects (PR32019)Vedant Kumar2017-02-251-6/+13
| | | | | | | | | | | | | | | | | | | | | | | | 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
* [profiling] PR31992: Don't skip interesting non-base constructorsVedant Kumar2017-02-241-4/+8
| | | | | | | | | 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
* Reuse a local variable. NFC.Vedant Kumar2017-02-181-5/+3
| | | | llvm-svn: 295527
* [Coverage] Support for C++17 if initializersVedant Kumar2016-10-141-0/+2
| | | | | | Differential Revision: https://reviews.llvm.org/D25572 llvm-svn: 284293
* [Coverage] Support for C++17 switch initializersVedant Kumar2016-10-141-0/+2
| | | | | | Differential Revision: https://reviews.llvm.org/D25539 llvm-svn: 284292
* [Coverage] Move logic to skip decl's into a helper (NFC)Vedant Kumar2016-07-111-9/+11
| | | | llvm-svn: 275120
* Reapply^3 "[ProfileData] (clang) Use Error in InstrProf and Coverage, NFC"Vedant Kumar2016-05-191-6/+7
| | | | | | Sync up with "(llvm) Use Error in InstrProf and Coverage". llvm-svn: 270021
* Revert "Reapply^2 "[ProfileData] (clang) Use Error in InstrProf and ↵Vedant Kumar2016-05-161-7/+6
| | | | | | | | Coverage, NFC"" This reverts commit r269695. The llvm commit does not pass the MSVC bot. llvm-svn: 269701
* Reapply^2 "[ProfileData] (clang) Use Error in InstrProf and Coverage, NFC"Vedant Kumar2016-05-161-6/+7
| | | | | | | | Sync up with "(llvm) Use Error in InstrProf and Coverage". Differential Revision: http://reviews.llvm.org/D19902 llvm-svn: 269695
* Revert "Reapply "[ProfileData] (clang) Use Error in InstrProf and Coverage, ↵Chandler Carruth2016-05-141-7/+6
| | | | | | | | | | 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
* Reapply "[ProfileData] (clang) Use Error in InstrProf and Coverage, NFC"Vedant Kumar2016-05-131-6/+7
| | | | | | | | Sync up with "(llvm) Use Error in InstrProf and Coverage". Differential Revision: http://reviews.llvm.org/D19902 llvm-svn: 269492
* Revert "[ProfileData] (clang) Use Error in InstrProf and Coverage, NFC"Vedant Kumar2016-05-131-7/+6
| | | | | | This reverts commit r269463. It fails two llvm-profdata tests. llvm-svn: 269468
* [ProfileData] (clang) Use Error in InstrProf and Coverage, NFCVedant Kumar2016-05-131-6/+7
| | | | | | Sync up with "(llvm) Use Error in InstrProf and Coverage". llvm-svn: 269463
* PGO] PGOFuncName meta data if PGOFuncName is different from function's raw nameRong Xu2016-04-221-0/+2
| | | | | | | | | | 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
* [PGO] Avoid instrumenting constants at value sitesBetul Buyukkurt2016-03-311-0/+3
| | | | | | | | | | 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
* [PGO] Move the instrumentation point closer to the value site.Betul Buyukkurt2016-03-291-3/+4
| | | | | | | | | 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
* P0184R0: Allow types of 'begin' and 'end' expressions in range-based for ↵Richard Smith2016-03-201-1/+2
| | | | | | loops to differ. llvm-svn: 263895
* [PGO] code simplification: use existing VP annotation API /NFCXinliang David Li2016-02-041-27/+3
| | | | llvm-svn: 259819
* [PGO] cc1 option name change for profile instrumentationRong Xu2016-02-041-4/+4
| | | | | | | | | | | | 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
* Clang changes for value profilingBetul Buyukkurt2016-01-231-4/+81
| | | | | | Differential Revision: http://reviews.llvm.org/D8940 llvm-svn: 258650
* [PGO] Simplify coverage mapping loweringXinliang David Li2016-01-071-1/+1
| | | | | | | | | | | | | | | | Coverage mapping data may reference names of functions that are skipped by FE (e.g, unused inline functions). Since those functions are skipped, normal instr-prof function lowering pass won't put those names in the right section, so special handling is needed to walk through coverage mapping structure and recollect the references. With this patch, only names that are skipped are processed. This simplifies the lowering code and it no longer needs to make assumptions coverage mapping data layout. It should also be more efficient. llvm-svn: 257092
* Remove setting of inlinehint and cold attributes based on profile dataEaswaran Raman2016-01-041-10/+0
| | | | | | | | | | | NFC. These hints are only used for inlining and the inliner now uses the same criteria to identify hot and cold callees and set appropriate thresholds without relying on these hints. Hence this removed code is superfluous. Differential Revision: http://reviews.llvm.org/D15726 llvm-svn: 256793
* [PGO] Instrument only base constructors and destructors.Serge Pavlov2015-12-061-15/+12
| | | | | | | | | | | | | | | | Constructors and destructors may be represented by several functions in IR. Only base structors correspond to source code, others are small pieces of code and eventually call the base variant. In this case instrumentation of non-base structors has little sense, this fix remove it. Now profile data of a declaration corresponds to exactly one function in IR, it agrees with the current logic of the profile data loading. This change fixes PR24996. Differential Revision: http://reviews.llvm.org/D15158 llvm-svn: 254876
* Pass profile version info to name API (NFC)Xinliang David Li2015-12-051-1/+4
| | | | llvm-svn: 254839
* [PGO] Code cleanup [NFC]Xinliang David Li2015-11-091-43/+2
| | | | | | | Use interfaces defined in LLVM to create FuncName and FuncNameVar. llvm-svn: 252434
* CodeGen: Remove implicit ilist iterator conversions, NFCDuncan P. N. Exon Smith2015-11-061-1/+1
| | | | | | | Make ilist iterator conversions explicit in clangCodeGen. Eventually I'll remove them everywhere. llvm-svn: 252358
* Use newly introduced interfaces in LLVM (NFC)Xinliang David Li2015-10-221-1/+1
| | | | | | | Replaced references to raw strings in instrumentation and coverage code. llvm-svn: 251072
* Fix Clang-tidy modernize-use-nullptr warnings in source directories; other ↵Hans Wennborg2015-10-061-2/+2
| | | | | | | | | | minor cleanups Patch by Eugene Zelenko! Differential Revision: http://reviews.llvm.org/D13406 llvm-svn: 249484
* Switch users of the 'for (StmtRange range = stmt->children(); range; ↵Benjamin Kramer2015-07-021-4/+3
| | | | | | | | | ++range)‘ pattern to range for loops. The pattern was born out of the lack of range-based for loops in C++98 and is somewhat obscure. No functionality change intended. llvm-svn: 241300
* Revert r240270 ("Fixed/added namespace ending comments using clang-tidy").Alexander Kornienko2015-06-221-1/+1
| | | | llvm-svn: 240353
* Fixed/added namespace ending comments using clang-tidy. NFCAlexander Kornienko2015-06-221-1/+1
| | | | | | | | | | | | The patch is generated using this command: $ tools/extra/clang-tidy/tool/run-clang-tidy.py -fix \ -checks=-*,llvm-namespace-comment -header-filter='llvm/.*|clang/.*' \ work/llvm/tools/clang To reduce churn, not touching namespaces spanning less than 10 lines. llvm-svn: 240270
* Set function entry counts with -fprofile-instr-use.Diego Novillo2015-05-271-0/+2
| | | | | | This generates function entry counts from instrumentation profiles. llvm-svn: 238360
* API update for streamlining of IRBuilder::CreateCall to just use ↵David Blaikie2015-05-181-3/+3
| | | | | | ArrayRef/initializer_list+braced init llvm-svn: 237625
* InstrProf: Cede ownership of createProfileWeights to CGFJustin Bogner2015-05-021-9/+10
| | | | | | | | The fact that PGO has a say in how these branch weights are determined isn't interesting to most of CodeGen, so it makes more sense for this API to be accessible via CodeGenFunction rather than CodeGenPGO. llvm-svn: 236380
* InstrProf: Use a locally tracked current count in ComputeRegionCountsJustin Bogner2015-05-021-33/+35
| | | | | | | | No functional change. This just makes it more obvious that the logic in ComputeRegionCounts only depends on the counter map and local state. llvm-svn: 236370
* InstrProf: Replace the RegionCounter class with a simpler direct approachJustin Bogner2015-05-011-130/+111
| | | | | | | | | This removes the RegionCounter class, which is only used as a helper in teh ComputeRegionCounts stmt visitor. This class is just an extra layer of abstraction that makes the code harder to follow at this point, and removing it makes the logic quite a bit more direct. llvm-svn: 236364
* InstrProf: Fix handling of profile counters in the body of range based forJustin Bogner2015-04-301-3/+2
| | | | | | | | | We were assigning the counter for the body of the loop to the loop variable initialization for some reason here, but our tests completely lacked coverage for range-for loops. This fixes that and makes the logic generally more similar to the logic for a regular for. llvm-svn: 236277
* InstrProf: Mark code regions after throw expressions as unreachableJustin Bogner2015-04-281-0/+8
| | | | | | | We weren't setting regions as being unreachable after C++ throw expressions, leading to incorrect count propagations. llvm-svn: 235967
* InstrProf: Stop using RegionCounter outside of CodeGenPGO (NFC)Justin Bogner2015-04-231-3/+4
| | | | | | | | | The RegionCounter type does a lot of legwork, but most of it is only meaningful within the implementation of CodeGenPGO. The uses elsewhere in CodeGen generally just want to increment or read counters, so do that directly. llvm-svn: 235664
* InstrProf: Fix a shadowing error that would break length of profile namesJustin Bogner2015-04-231-2/+2
| | | | | | | | We try to use the member variable "FuncName" here, but we've also used that name as a parameter. This ends with us getting the length of the function name wrong when we generate the coverage data. llvm-svn: 235565
* InstrProf: Simplify getStmtCount by using an OptionalJustin Bogner2015-04-131-6/+4
| | | | llvm-svn: 234750
* InstrProf: Make profile variables private to reduce binary size overheadJustin Bogner2015-03-201-2/+6
| | | | | | | | | | | | When we instrument a program for profiling, we copy the linkage of an instrumented function so that our datastructures merge in the same way as the function. This avoids redundant copies for things like linkonce, but ends up emitting names we never need to reference for normal and internal symbols. Promoting internal and external linkage to private for these variables reduces the size overhead of profiling drastically. llvm-svn: 232799
OpenPOWER on IntegriCloud