summaryrefslogtreecommitdiffstats
path: root/clang/test/Profile
Commit message (Collapse)AuthorAgeFilesLines
* [PGO] Fix bolt failures from r367628Rong Xu2019-08-021-2/+2
| | | | | | | Relaxed the check in a test because the windows bolt generates different profile variables. llvm-svn: 367657
* [PGO] Add PGO support at -O0 in the experimental new pass managerRong Xu2019-08-012-7/+42
| | | | | | | | | | | | | | Add PGO support at -O0 in the experimental new pass manager to sync the behavior of the legacy pass manager. Also change the test of gcc-flag-compatibility.c for more complete test: (1) change the match string to "profc" and "profd" to ensure the instrumentation is happening. (2) add IR format proftext so that PGO use compilation is tested. Differential Revision: https://reviews.llvm.org/D64029 llvm-svn: 367628
* Revert "[clang][NewPM] Fix broken profile test"Leonard Chan2019-06-291-8/+4
| | | | | | | | This reverts commit ab2c0ed01edfec9a9402d03bdf8633b34b73f3a7. See https://reviews.llvm.org/D63155 llvm-svn: 364692
* [clang][NewPM] Fix broken profile testLeonard Chan2019-06-131-4/+8
| | | | | | | | | | This contains the part of D62225 which fixes Profile/gcc-flag-compatibility.c by adding the pass that allows default profile generation to work under the new PM. It seems that ./default.profraw was not being generated with new PM enabled. Differential Revision: https://reviews.llvm.org/D63155 llvm-svn: 363278
* [PGO] Fix buildbot failure in 359215Rong Xu2019-04-251-2/+0
| | | | | | | Revert the part of changes in r359215 that failing in some platforms. I will re-enable them later. llvm-svn: 359241
* [PGO] Enable InstrProf lowering for Clang PGO instrumentation in the new ↵Rong Xu2019-04-251-0/+2
| | | | | | | | | | | | | | | pass manager Currently InstrProf lowering is not enabled for Clang PGO instrumentation in the new pass manager. The following command "-fprofile-instr-generate -fexperimental-new-pass-manager ..." is broken. This CL enables InstrProf lowering pass for Clang PGO instrumentation in the new pass manager. Differential Revision: https://reviews.llvm.org/D61138 llvm-svn: 359215
* [InstrProf] Use separate comdat group for data and countersReid Kleckner2019-02-271-2/+2
| | | | | | | | | | | | | | | | | | | | | | | Summary: I hadn't realized that instrumentation runs before inlining, so we can't use the function as the comdat group. Doing so can create relocations against discarded sections when references to discarded __profc_ variables are inlined into functions outside the function's comdat group. In the future, perhaps we should consider standardizing the comdat group names that ELF and COFF use. It will save object file size, since __profv_$sym won't appear in the symbol table again. Reviewers: xur, vsk Subscribers: eraman, hiraditya, cfe-commits, #sanitizers, llvm-commits Tags: #clang, #sanitizers, #llvm Differential Revision: https://reviews.llvm.org/D58737 llvm-svn: 355044
* [MS] Don't emit coverage for deleting dtorsReid Kleckner2019-02-261-0/+83
| | | | | | | | | | | | | | | | | | | 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
* Fix clang tests broken by r353547 that depend on InstrProfReid Kleckner2019-02-106-14/+14
| | | | llvm-svn: 353653
* [FileCheck] Add -allow-deprecated-dag-overlap to failing clang testsJoel E. Denny2018-07-113-10/+10
| | | | | | | | | | See https://reviews.llvm.org/D47106 for details. Reviewed By: probinson Differential Revision: https://reviews.llvm.org/D47172 llvm-svn: 336844
* [PGO] Detect more structural changes with the stable hashVedant Kumar2017-11-1417-49/+494
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-302-0/+30
| | | | | | | | | 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
* Fix a typo. NFC.Vedant Kumar2017-06-301-1/+1
| | | | llvm-svn: 306882
* [Profile] Add off-by-default -Wprofile-instr-missing warningVedant Kumar2017-04-271-8/+8
| | | | | | | | | | | | | | | Clang warns that a profile is out-of-date if it can't find a profile record for any function in a TU. This warning became noisy after llvm started allowing dead-stripping of instrumented functions. To fix this, this patch changes the existing profile out-of-date warning (-Wprofile-instr-out-of-date) so that it only complains about mismatched data. Further, it introduces a new, off-by-default warning about missing function data (-Wprofile-instr-missing). Differential Revision: https://reviews.llvm.org/D28867 llvm-svn: 301570
* Weaken test/Profile/c-ternary.cVedant Kumar2017-02-251-1/+1
| | | | | | | | | There is a bot which doesn't use '%1' as the IR name of the first argument to a function: http://lab.llvm.org:8011/builders/clang-with-thin-lto-ubuntu/builds/2050/steps/test-stage1-compiler/logs/stdio llvm-svn: 296248
* Retry: [profiling] Fix profile counter increment when emitting selects (PR32019)Vedant Kumar2017-02-251-0/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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-15/+0
| | | | | | | | | | | | | | | | | | | | | (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-0/+15
| | | | | | | | | | | | | | | | | | | | | | | | 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-243-1/+62
| | | | | | | | | 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
* [profiling] Make a test more explicit. NFC.Vedant Kumar2017-02-181-7/+15
| | | | | | | | The cxx-structors.cpp test checks that some instrumentation doesn't appear, but it should be more explicit about which instrumentation it actually expects to appear. llvm-svn: 295532
* [profiling] Tighten test cases which refer to "profn" vars. NFC.Vedant Kumar2017-02-182-7/+7
| | | | | | | | The frontend can't see "__profn" profile name variables after IRGen because llvm throws these away now. Tighten up some test cases which checked for the non-existence of those variables. llvm-svn: 295528
* [profiling] Update test cases to deal with name variable change (NFC)Vedant Kumar2017-02-141-9/+0
| | | | | | | | | This is a re-try of r295085: fix up some test cases that assume that profile name variables are preserved by the instrprof pass. This catches one additional case in test/CoverageMapping/unused_names.c. llvm-svn: 295101
* Revert "[profiling] Update test case to deal with name variable change (NFC)"Vedant Kumar2017-02-141-0/+9
| | | | | | | This reverts commit r295085, because the corresponding llvm change was reverted. llvm-svn: 295100
* [profiling] Update test case to deal with name variable change (NFC)Vedant Kumar2017-02-141-9/+0
| | | | | | | The 'profn' name variables shouldn't show up after we run the instrprof pass, see https://reviews.llvm.org/D29921 for more details. llvm-svn: 295085
* Fix two test cases I missed updating in r291850. Sorry for the noise.Chandler Carruth2017-01-121-2/+2
| | | | llvm-svn: 291853
* Make '-disable-llvm-optzns' an alias for '-disable-llvm-passes'.Chandler Carruth2016-12-233-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | Much to my surprise, '-disable-llvm-optzns' which I thought was the magical flag I wanted to get at the raw LLVM IR coming out of Clang deosn't do that. It still runs some passes over the IR. I don't want that, I really want the *raw* IR coming out of Clang and I strongly suspect everyone else using it is in the same camp. There is actually a flag that does what I want that I didn't know about called '-disable-llvm-passes'. I suspect many others don't know about it either. It both does what I want and is much simpler. This removes the confusing version and makes that spelling of the flag an alias for '-disable-llvm-passes'. I've also moved everything in Clang to use the 'passes' spelling as it seems both more accurate (*all* LLVM passes are disabled, not just optimizations) and much easier to remember and spell correctly. This is part of simplifying how Clang drives LLVM to make it cleaner to wire up to the new pass manager. Differential Revision: https://reviews.llvm.org/D28047 llvm-svn: 290392
* Add test for D21736.Marcin Koscielnicki2016-11-222-7/+13
| | | | | | Differential Revision: http://reviews.llvm.org/D21741 llvm-svn: 287689
* [Coverage] Support for C++17 if initializersVedant Kumar2016-10-141-0/+12
| | | | | | Differential Revision: https://reviews.llvm.org/D25572 llvm-svn: 284293
* [Coverage] Support for C++17 switch initializersVedant Kumar2016-10-141-0/+17
| | | | | | Differential Revision: https://reviews.llvm.org/D25539 llvm-svn: 284292
* [Profile] Update testcase for r283948 (NFC)Vedant Kumar2016-10-111-1/+1
| | | | | | | | | | | Old: "__DATA,__llvm_prf_data" New: "__DATA,__llvm_prf_data,regular,live_support" This should fix the following bot failure: http://bb.pgr.jp/builders/cmake-clang-x86_64-linux/builds/55158 llvm-svn: 283949
* [Profile] Enable profile merging with -fprofile-generat[=<dir>]Xinliang David Li2016-07-221-1/+1
| | | | | | | This patch enables raw profile merging for this option which is the new intended behavior. llvm-svn: 276484
* [profile] update test case with interface change.Xinliang David Li2016-07-212-10/+3
| | | | | | See http://reviews.llvm.org/D22613, http://reviews.llvm.org/D22614 llvm-svn: 276356
* [Driver] Add flags for enabling both types of PGO InstrumentationSean Silva2016-07-161-3/+4
| | | | | | | | | | | | The flags: Enable IR-level instrumentation -fprofile-generate or -fprofile-generate= When applying profile data: -fprofile-use=/path/to/profdata Patch by Jake VanAdrighem! Differential Revision: https://reviews.llvm.org/D21823 llvm-svn: 275668
* Remove MaxFunctionCount module flag annotation.Easwaran Raman2016-06-201-24/+0
| | | | | | Differential revision: http://reviews.llvm.org/D19184 llvm-svn: 273198
* [profile] Fix another use of the driver.Sean Silva2016-04-231-1/+1
| | | | | | Follow-on to r267262. llvm-svn: 267263
* [profile] Use cc1 in these tests instead of the driver.Sean Silva2016-04-235-9/+9
| | | | | | | I ran into this when seeing what tests would break if we make a driver-level decision about whether FEPGO or IRPGO is the default. llvm-svn: 267262
* [PGO] Avoid instrumenting constants at value sitesBetul Buyukkurt2016-03-311-0/+11
| | | | | | | | | | 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] Test case fix for r264783 Betul Buyukkurt2016-03-291-1/+1
| | | | llvm-svn: 264795
* [PGO] Move the instrumentation point closer to the value site.Betul Buyukkurt2016-03-292-2/+24
| | | | | | | | | 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
* Attach profile summary information to Module.Easwaran Raman2016-03-242-0/+51
| | | | | | Differential Revision: http://reviews.llvm.org/D18289 llvm-svn: 264342
* [PGO] Change profile use cc1 option to handle IR level profilesRong Xu2016-03-0211-13/+13
| | | | | | | | | | | | | | | | | | This patch changes cc1 option for PGO profile use from -fprofile-instr-use=<path> to -fprofile-instrument-use-path=<path>. -fprofile-instr-use=<path> is now a driver only option. In addition to decouple the cc1 option from the driver level option, this patch also enables IR level profile use. cc1 option handling now reads the profile header and sets CodeGenOpt ProfileUse (valid values are {None, Clang, LLVM} -- this is a common enum for -fprofile-instrument={}, for the profile instrumentation), and invoke the pipeline to enable the respective PGO use pass. Reviewers: silvas, davidxl Differential Revision: http://reviews.llvm.org/D17737 llvm-svn: 262515
* Test simplificationXinliang David Li2016-02-171-3/+2
| | | | llvm-svn: 261047
* [PGO] Fix issue: explicitly defaulted assignop is not profiledXinliang David Li2016-02-091-0/+32
| | | | | | | Differential Revision: http://reviews.llvm.org/D16947 llvm-svn: 260270
* [PGO] Cover more cases of implicitly generated C++ methodsXinliang David Li2016-02-081-4/+38
| | | | llvm-svn: 260161
* Simplify test casesXinliang David Li2016-02-082-22/+8
| | | | llvm-svn: 260126
* Fix test case problem(caused by clang-formatXinliang David Li2016-02-072-12/+4
| | | | llvm-svn: 260022
* [PGO] add profile/coverage test cases for defaulted ctor/ctorsXinliang David Li2016-02-072-0/+88
| | | | llvm-svn: 260021
* [PGO] cc1 option name change for profile instrumentationRong Xu2016-02-0415-20/+25
| | | | | | | | | | | | 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
* [PGO] test case cleanupsXinliang David Li2016-01-284-15/+21
| | | | | | | 1. Make test case more focused and robust by focusing on what to be tested (linkage, icall) -- make it easier to validate 2. Testing linkages of data and counter variables instead of names. Counters and data are more relavant to be tested. llvm-svn: 259067
* Clang changes for value profilingBetul Buyukkurt2016-01-231-0/+15
| | | | | | Differential Revision: http://reviews.llvm.org/D8940 llvm-svn: 258650
OpenPOWER on IntegriCloud