summaryrefslogtreecommitdiffstats
path: root/clang/test/Profile
Commit message (Collapse)AuthorAgeFilesLines
* Revert "[Coverage] Revise format to reduce binary size"Vedant Kumar2019-12-043-19/+8
| | | | | | | | | | This reverts commit e18531595bba495946aa52c0a16b9f9238cff8bc. On Windows, there is an error: http://lab.llvm.org:8011/builders/sanitizer-windows/builds/54963/steps/stage%201%20check/logs/stdio error: C:\b\slave\sanitizer-windows\build\stage1\projects\compiler-rt\test\profile\Profile-x86_64\Output\instrprof-merging.cpp.tmp.v1.o: Failed to load coverage: Malformed coverage data
* [Coverage] Revise format to reduce binary sizeVedant Kumar2019-12-043-8/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Revise the coverage mapping format to reduce binary size by: 1. Naming function records and marking them `linkonce_odr`, and 2. Compressing filenames. This shrinks the size of llc's coverage segment by 82% (334MB -> 62MB) and speeds up end-to-end single-threaded report generation by 10%. For reference the compressed name data in llc is 81MB (__llvm_prf_names). Rationale for changes to the format: - With the current format, most coverage function records are discarded. E.g., more than 97% of the records in llc are *duplicate* placeholders for functions visible-but-not-used in TUs. Placeholders *are* used to show under-covered functions, but duplicate placeholders waste space. - We reached general consensus about giving (1) a try at the 2017 code coverage BoF [1]. The thinking was that using `linkonce_odr` to merge duplicates is simpler than alternatives like teaching build systems about a coverage-aware database/module/etc on the side. - Revising the format is expensive due to the backwards compatibility requirement, so we might as well compress filenames while we're at it. This shrinks the encoded filenames in llc by 86% (12MB -> 1.6MB). See CoverageMappingFormat.rst for the details on what exactly has changed. Fixes PR34533 [2], hopefully. [1] http://lists.llvm.org/pipermail/llvm-dev/2017-October/118428.html [2] https://bugs.llvm.org/show_bug.cgi?id=34533 Differential Revision: https://reviews.llvm.org/D69471
* Update clang tests for new LLVM IR backslash printing in r374415Reid Kleckner2019-10-101-1/+1
| | | | llvm-svn: 374416
* Reland "clang-misexpect: Profile Guided Validation of Performance ↵Petr Hosek2019-09-1114-0/+340
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Annotations in LLVM" This patch contains the basic functionality for reporting potentially incorrect usage of __builtin_expect() by comparing the developer's annotation against a collected PGO profile. A more detailed proposal and discussion appears on the CFE-dev mailing list (http://lists.llvm.org/pipermail/cfe-dev/2019-July/062971.html) and a prototype of the initial frontend changes appear here in D65300 We revised the work in D65300 by moving the misexpect check into the LLVM backend, and adding support for IR and sampling based profiles, in addition to frontend instrumentation. We add new misexpect metadata tags to those instructions directly influenced by the llvm.expect intrinsic (branch, switch, and select) when lowering the intrinsics. The misexpect metadata contains information about the expected target of the intrinsic so that we can check against the correct PGO counter when emitting diagnostics, and the compiler's values for the LikelyBranchWeight and UnlikelyBranchWeight. We use these branch weight values to determine when to emit the diagnostic to the user. A future patch should address the comment at the top of LowerExpectIntrisic.cpp to hoist the LikelyBranchWeight and UnlikelyBranchWeight values into a shared space that can be accessed outside of the LowerExpectIntrinsic pass. Once that is done, the misexpect metadata can be updated to be smaller. In the long term, it is possible to reconstruct portions of the misexpect metadata from the existing profile data. However, we have avoided this to keep the code simple, and because some kind of metadata tag will be required to identify which branch/switch/select instructions are influenced by the use of llvm.expect Patch By: paulkirth Differential Revision: https://reviews.llvm.org/D66324 llvm-svn: 371635
* Revert "clang-misexpect: Profile Guided Validation of Performance ↵Dmitri Gribenko2019-09-1114-340/+0
| | | | | | | | | | | | | | | | | | | Annotations in LLVM" This reverts commit r371584. It introduced a dependency from compiler-rt to llvm/include/ADT, which is problematic for multiple reasons. One is that it is a novel dependency edge, which needs cross-compliation machinery for llvm/include/ADT (yes, it is true that right now compiler-rt included only header-only libraries, however, if we allow compiler-rt to depend on anything from ADT, other libraries will eventually get used). Secondly, depending on ADT from compiler-rt exposes ADT symbols from compiler-rt, which would cause ODR violations when Clang is built with the profile library. llvm-svn: 371598
* clang-misexpect: Profile Guided Validation of Performance Annotations in LLVMPetr Hosek2019-09-1114-0/+340
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch contains the basic functionality for reporting potentially incorrect usage of __builtin_expect() by comparing the developer's annotation against a collected PGO profile. A more detailed proposal and discussion appears on the CFE-dev mailing list (http://lists.llvm.org/pipermail/cfe-dev/2019-July/062971.html) and a prototype of the initial frontend changes appear here in D65300 We revised the work in D65300 by moving the misexpect check into the LLVM backend, and adding support for IR and sampling based profiles, in addition to frontend instrumentation. We add new misexpect metadata tags to those instructions directly influenced by the llvm.expect intrinsic (branch, switch, and select) when lowering the intrinsics. The misexpect metadata contains information about the expected target of the intrinsic so that we can check against the correct PGO counter when emitting diagnostics, and the compiler's values for the LikelyBranchWeight and UnlikelyBranchWeight. We use these branch weight values to determine when to emit the diagnostic to the user. A future patch should address the comment at the top of LowerExpectIntrisic.cpp to hoist the LikelyBranchWeight and UnlikelyBranchWeight values into a shared space that can be accessed outside of the LowerExpectIntrinsic pass. Once that is done, the misexpect metadata can be updated to be smaller. In the long term, it is possible to reconstruct portions of the misexpect metadata from the existing profile data. However, we have avoided this to keep the code simple, and because some kind of metadata tag will be required to identify which branch/switch/select instructions are influenced by the use of llvm.expect Patch By: paulkirth Differential Revision: https://reviews.llvm.org/D66324 llvm-svn: 371584
* Revert "clang-misexpect: Profile Guided Validation of Performance ↵Petr Hosek2019-09-1013-323/+0
| | | | | | | | Annotations in LLVM" This reverts commit r371484: this broke sanitizer-x86_64-linux-fast bot. llvm-svn: 371488
* clang-misexpect: Profile Guided Validation of Performance Annotations in LLVMPetr Hosek2019-09-1013-0/+323
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch contains the basic functionality for reporting potentially incorrect usage of __builtin_expect() by comparing the developer's annotation against a collected PGO profile. A more detailed proposal and discussion appears on the CFE-dev mailing list (http://lists.llvm.org/pipermail/cfe-dev/2019-July/062971.html) and a prototype of the initial frontend changes appear here in D65300 We revised the work in D65300 by moving the misexpect check into the LLVM backend, and adding support for IR and sampling based profiles, in addition to frontend instrumentation. We add new misexpect metadata tags to those instructions directly influenced by the llvm.expect intrinsic (branch, switch, and select) when lowering the intrinsics. The misexpect metadata contains information about the expected target of the intrinsic so that we can check against the correct PGO counter when emitting diagnostics, and the compiler's values for the LikelyBranchWeight and UnlikelyBranchWeight. We use these branch weight values to determine when to emit the diagnostic to the user. A future patch should address the comment at the top of LowerExpectIntrisic.cpp to hoist the LikelyBranchWeight and UnlikelyBranchWeight values into a shared space that can be accessed outside of the LowerExpectIntrinsic pass. Once that is done, the misexpect metadata can be updated to be smaller. In the long term, it is possible to reconstruct portions of the misexpect metadata from the existing profile data. However, we have avoided this to keep the code simple, and because some kind of metadata tag will be required to identify which branch/switch/select instructions are influenced by the use of llvm.expect Patch By: paulkirth Differential Revision: https://reviews.llvm.org/D66324 llvm-svn: 371484
* [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
OpenPOWER on IntegriCloud