summaryrefslogtreecommitdiffstats
path: root/llvm/lib/ProfileData
Commit message (Collapse)AuthorAgeFilesLines
...
* [Coverage] Simplify r316141. NFC.Vedant Kumar2017-10-191-3/+3
| | | | llvm-svn: 316147
* [llvm-cov] Move LineCoverageIterator to libCoverage. NFC.Vedant Kumar2017-10-181-0/+53
| | | | | | | | | | | | | LineCoverageIterator makes it easy for clients of coverage data to determine line execution counts for a file or function. The coverage iteration logic is tricky enough that it really pays not to have multiple copies of it. Hopefully having just one implementation in LLVM will make the iteration logic easier to test, reuse, and update. This commit is NFC but I've added a unit test to go along with it just because it's easy to do now. llvm-svn: 316141
* Reverting r315590; it did not include changes for llvm-tblgen, which is ↵Aaron Ballman2017-10-151-3/+3
| | | | | | | | causing link errors for several people. Error LNK2019 unresolved external symbol "public: void __cdecl `anonymous namespace'::MatchableInfo::dump(void)const " (?dump@MatchableInfo@?A0xf4f1c304@@QEBAXXZ) referenced in function "public: void __cdecl `anonymous namespace'::AsmMatcherEmitter::run(class llvm::raw_ostream &)" (?run@AsmMatcherEmitter@?A0xf4f1c304@@QEAAXAEAVraw_ostream@llvm@@@Z) llvm-tblgen D:\llvm\2017\utils\TableGen\AsmMatcherEmitter.obj 1 llvm-svn: 315854
* [dump] Remove NDEBUG from test to enable dump methods [NFC]Don Hinton2017-10-121-3/+3
| | | | | | | | | | | | | | | Summary: Add LLVM_FORCE_ENABLE_DUMP cmake option, and use it along with LLVM_ENABLE_ASSERTIONS to set LLVM_ENABLE_DUMP. Remove NDEBUG and only use LLVM_ENABLE_DUMP to enable dump methods. Move definition of LLVM_ENABLE_DUMP from config.h to llvm-config.h so it'll be picked up by public headers. Differential Revision: https://reviews.llvm.org/D38406 llvm-svn: 315590
* Fix warnings. [-Wdocumentation]NAKAMURA Takumi2017-10-122-8/+0
| | | | llvm-svn: 315573
* [ProfileData] Fix data racing in merging indexed profilesRong Xu2017-10-051-2/+0
| | | | | | | | | | There is data racing to the static variable RecordIndex in index profile reader when merging in multiple threads. Make it a member variable in IndexedInstrProfReader to fix this. Differential Revision: https://reviews.llvm.org/D38431 llvm-svn: 314990
* [llvm-cov] Improve error messaging for function mismatchesVedant Kumar2017-09-211-2/+3
| | | | | | | | | Passing "-dump" to llvm-cov will now print more detailed information about function hash and counter mismatches. This should make it easier to debug *.profdata files which contain incorrect records, and to debug other scenarios where coverage goes missing due to mismatch issues. llvm-svn: 313853
* [Coverage] Use gap regions to select better line exec countsVedant Kumar2017-09-183-7/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | After clang started emitting deferred regions (r312818), llvm-cov has had a hard time picking reasonable line execuction counts. There have been one or two generic improvements in this area (e.g r310012), but line counts can still report coverage for whitespace instead of code (llvm.org/PR34612). To fix the problem: * Introduce a new region kind so that frontends can explicitly label gap areas. This is done by changing the encoding of the columnEnd field of MappingRegion. This doesn't substantially increase binary size, and makes it easy to maintain backwards-compatibility. * Don't set the line count to a count from a gap area, unless the count comes from a wrapped segment. * Don't highlight gap areas as uncovered. Fixes llvm.org/PR34612. llvm-svn: 313597
* [Coverage] Build sorted and unique segmentsVedant Kumar2017-09-081-46/+138
| | | | | | | | | | | | | | | | | | | | | | | | A coverage segment contains a starting line and column, an execution count, and some other metadata. Clients of the coverage library use segments to prepare line-oriented reports. Users of the coverage library depend on segments being unique and sorted in source order. Currently this is not guaranteed (this is why the clang change which introduced deferred regions was reverted). This commit documents the "unique and sorted" condition and asserts that it holds. It also fixes the SegmentBuilder so that it produces correct output in some edge cases. Testing: I've added unit tests for some edge cases. I've also checked that the new SegmentBuilder implementation is fully covered. Apart from running check-profile and the llvm-cov tests, I've successfully used a stage1 llvm-cov to prepare a coverage report for an instrumented clang binary. Differential Revision: https://reviews.llvm.org/D36813 llvm-svn: 312817
* [Coverage] Define LineColPair for convenience. NFC.Vedant Kumar2017-09-081-2/+1
| | | | llvm-svn: 312815
* [Coverage] Report errors when reading malformed source regionsVedant Kumar2017-09-083-8/+25
| | | | | | | | | | | | | Each source region has a start and end location. Report an error when the end location does not precede the begin location. The old lineExecutionCounts.covmapping test actually had a buggy source region in it. This commit introduces a regenerated copy of the coverage and moves the old copy to malformedRegions.covmapping, for a test. Differential Revision: https://reviews.llvm.org/D37387 llvm-svn: 312814
* Fix the bug when SampleProfileWriter writes out number of callsites.Dehao Chen2017-08-031-1/+4
| | | | | | | | | | | | | | Summary: As we support multiple callsites for the same location, we need to traverse all locations to get the number of callsites. Reviewers: davidxl Reviewed By: davidxl Subscribers: sanjoy, llvm-commits Differential Revision: https://reviews.llvm.org/D36246 llvm-svn: 309907
* [Coverage] Add an API to retrive all instantiations of a function (NFC)Vedant Kumar2017-08-021-7/+7
| | | | | | | | | | | | | | | | | | | | | | | | | The CoverageMapping::getInstantiations() API retrieved all function records corresponding to functions with more than one instantiation (e.g template functions with multiple specializations). However, there was no simple way to determine *which* function a given record was an instantiation of. This was an oversight, since it's useful to aggregate coverage information over all instantiations of a function. llvm-cov works around this by building a mapping of source locations to instantiation sets, but this duplicates logic that libCoverage already has (see FunctionInstantiationSetCollector). This change adds a new API, CoverageMapping::getInstantiationGroups(), which returns a list of InstantiationGroups. A group contains records for each instantiation of some particular function, and also provides utilities to get the total execution count within the group, the source location of the common definition, etc. This lets removes some hacky logic in llvm-cov by reusing FunctionInstantiationSetCollector and makes the CoverageMapping API friendlier for other clients. llvm-svn: 309904
* [llvm-cov] Allow specifying distinct architectures for each loaded binaryVedant Kumar2017-08-011-3/+4
| | | | | | | | | | | The coverage tool needs to know which slice to look at when it's handed a universal binary. Some projects need to look at aggregate coverage reports for a variety of slices in different binaries: this patch adds support for these kinds of projects to llvm-cov. rdar://problem/33579007 llvm-svn: 309747
* [ProfData] Detect if zlib is availableDavid Blaikie2017-07-211-0/+5
| | | | | | | | | | | | As discussed on [1], if the profile is compressed and llvm-profdata is not built with zlib support, the error message is not informative. Give a better error message if zlib is not available. [1] http://lists.llvm.org/pipermail/llvm-dev/2017-July/115571.html Reviewers: davidxl, dblaikie Differential Revision: https://reviews.llvm.org/D35586 llvm-svn: 308789
* llvm-profdata: Reduce memory usage by using Error callback rather than memberDavid Blaikie2017-07-102-33/+40
| | | | | | | | | | | | | | | | Reduces llvm-profdata memory usage on a large profile from 7.8GB to 5.1GB. The ProfData API now supports reporting all the errors/warnings rather than only the first, though llvm-profdata ignores everything after the first for now to preserve existing behavior. (if there's a desire for other behavior, happy to implement that - but might be as well left for a separate patch) Reviewers: davidxl Differential Revision: https://reviews.llvm.org/D35149 llvm-svn: 307516
* Prototype: Reduce llvm-profdata merge memory usage furtherDavid Blaikie2017-07-062-20/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The InstrProfWriter already stores the name and hash of the record in the nested maps it uses for lookup while merging - this data is duplicated in the value within the maps. Refactor the InstrProfRecord to use a nested struct for the counters themselves so that InstrProfWriter can use this nested struct alone without the name or hash duplicated there. This work is incomplete, but enough to demonstrate the value (around a 50% decrease in memory usage for a large test case (10GB -> 5GB)). Though most of that decrease is probably from removing the SoftInstrProfError as well, but I haven't implemented a replacement for it yet. (it needs to go with the counters, because the operations on the counters - merging, etc, are where the failures are - unlike the name/hash which are totally unused by those counter-related operations and thus easy to split out) Ongoing discussion about removing SoftInstrProfError as a field of the InstrProfRecord is happening on the thread that added it - including the possibility of moving back towards an earlier version of that proposed patch that passed SoftInstrProfError through the various APIs, rather than as a member of InstrProfRecord. Reviewers: davidxl Differential Revision: https://reviews.llvm.org/D34838 llvm-svn: 307298
* [Coverage] Remove two overloads of CoverageMapping::load. NFC.Vedant Kumar2017-06-301-12/+0
| | | | | | | | | | These overloads are essentially dead, and pose a maintenance cost without adding any benefit. This is coming up now because I'd like to experiment with changing the way we store coverage mapping data, and would rather not have to fix up the old overloads while doing so. Testing: check-{llvm,profile}, build clang. llvm-svn: 306776
* llvm-profdata: Indirect infrequently used fields to reduce memory usageDavid Blaikie2017-06-291-8/+7
| | | | | | | | | | | | | | | | | | | | | | | | | Examining a large profile example, it seems relatively few records have non-empty IndirectCall and MemOP data, so indirecting these through a unique_ptr (non-null only when they are non-empty) Reduces memory usage on this particular example from 14GB to 10GB according to valgrind's massif. I suspect it'd still be worth moving InstrProfWriter to its own data structure that had Counts and the indirected IndirectCall+MemOP, and did not include the Name, Hash, or Error fields. This would reduce the size of this dominant data structure by half of this new, lower amount. (Name(2), Hash(1), Error(1) ~= Counts(vector, 3), ValueProfData (unique_ptr, 1)) -> From code review feedback, might actually refactor InstrProfRecord itself to have a sub-struct with all the counts, and use that from InstrProfWriter, rather than InstrProfWriter owning its own data structure for this. Reviewers: davidxl Differential Revision: https://reviews.llvm.org/D34694 llvm-svn: 306631
* [ProfData] Make the method threadsafeXinliang David Li2017-06-271-2/+3
| | | | llvm-svn: 306428
* [Coverage] Improve readability by using a struct. NFC.Vedant Kumar2017-06-261-22/+20
| | | | llvm-svn: 306340
* [ProfileData, Support] Fix some Clang-tidy modernize-use-using and Include ↵Eugene Zelenko2017-06-214-23/+21
| | | | | | What You Use warnings; other minor fixes (NFC). llvm-svn: 305969
* [Coverage] PR33517: Check for failure to load func recordsVedant Kumar2017-06-201-0/+3
| | | | | | | | | | | | With PR33517, it became apparent that symbol table creation can fail when presented with malformed inputs. This patch makes that sort of error detectable, so llvm-cov etc. can fail more gracefully. Specifically, we now check that function records loaded from corrupted coverage mapping data are rejected, e.g when the recorded function name is garbage. Testing: check-{llvm,clang,profile}, some unit test updates. llvm-svn: 305767
* [ProfileData] PR33517: Check for failure of symtab creationVedant Kumar2017-06-204-9/+21
| | | | | | | | | | | | With PR33517, it became apparent that symbol table creation can fail when presented with malformed inputs. This patch makes that sort of error detectable, so llvm-cov etc. can fail more gracefully. Specifically, we now check that function names within the symbol table aren't empty. Testing: check-{llvm,clang,profile}, some unit test updates. llvm-svn: 305765
* Sort the remaining #include lines in include/... and lib/....Chandler Carruth2017-06-066-7/+7
| | | | | | | | | | | | | | | | | | | | | | | | | I did this a long time ago with a janky python script, but now clang-format has built-in support for this. I fed clang-format every line with a #include and let it re-sort things according to the precise LLVM rules for include ordering baked into clang-format these days. I've reverted a number of files where the results of sorting includes isn't healthy. Either places where we have legacy code relying on particular include ordering (where possible, I'll fix these separately) or where we have particular formatting around #include lines that I didn't want to disturb in this patch. This patch is *entirely* mechanical. If you get merge conflicts or anything, just ignore the changes in this patch and run clang-format over your #include lines in the files. Sorry for any noise here, but it is important to keep these things stable. I was seeing an increasing number of patches with irrelevant re-ordering of #include lines because clang-format was used. This patch at least isolates that churn, makes it easy to skip when resolving conflicts, and gets us to a clean baseline (again). llvm-svn: 304787
* [InstrProf] Use more ArrayRef/StringRef.Benjamin Kramer2017-05-281-8/+8
| | | | | | No functional change intended. llvm-svn: 304089
* Change sample profile writer to make it deterministic.Dehao Chen2017-05-111-4/+38
| | | | | | | | | | | | | | Summary: This patch changes the function profile output order to be deterministic. In order to make it easier to understand, hottest functions (with most total samples) is ordered first. Reviewers: dnovillo, davidxl Reviewed By: dnovillo Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D33111 llvm-svn: 302851
* [ProfileData] Unify getInstrProf*SectionName helpersVedant Kumar2017-04-152-77/+21
| | | | | | | | | | | | | | | | | | | | | | This is a version of D32090 that unifies all of the `getInstrProf*SectionName` helper functions. (Note: the build failures which D32090 would have addressed were fixed with r300352.) We should unify these helper functions because they are hard to use in their current form. E.g we recently introduced more helpers to fix section naming for COFF files. This scheme doesn't totally succeed at hiding low-level details about section naming, so we should switch to an API that is easier to maintain. This is not an NFC commit because it fixes llvm-cov's testing support for COFF files (this falls out of the API change naturally). This is an area where we lack tests -- I will see about adding one as a follow up. Testing: check-clang, check-profile, check-llvm. Differential Revision: https://reviews.llvm.org/D32097 llvm-svn: 300381
* [Profile] Make host tool aware of object format when quering prof section names Xinliang David Li2017-04-142-12/+26
| | | | | | Differential Revision: https://reviews.llvm.org/D32073 llvm-svn: 300352
* [Profile] PE binary coverage bug fixXinliang David Li2017-04-132-3/+91
| | | | | | | | PR/32584 Differential Revision: https://reviews.llvm.org/D32023 llvm-svn: 300277
* SamplePGO: convert callsite samples map key from callsite_location to ↵Dehao Chen2017-04-133-33/+38
| | | | | | | | | | | | | | | | callsite_location+callee_name Summary: For iterative SamplePGO, an indirect call can be speculatively promoted to multiple direct calls and get inlined. All these promoted direct calls will share the same callsite location (offset+discriminator). With the current implementation, we cannot distinguish between different promotion candidates and its inlined instance. This patch adds callee_name to the key of the callsite sample map. And added helper functions to get all inlined callee samples for a given callsite location. This helps the profile annotator promote correct targets and inline it before annotation, and ensures all indirect call targets to be annotated correctly. Reviewers: davidxl, dnovillo Reviewed By: davidxl Subscribers: andreadb, llvm-commits Differential Revision: https://reviews.llvm.org/D31950 llvm-svn: 300240
* [PGO] Memory intrinsic calls optimization based on profiled sizeRong Xu2017-04-041-0/+21
| | | | | | | | | | | | | | | | | | | | | | | | This patch optimizes two memory intrinsic operations: memset and memcpy based on the profiled size of the operation. The high level transformation is like: mem_op(..., size) ==> switch (size) { case s1: mem_op(..., s1); goto merge_bb; case s2: mem_op(..., s2); goto merge_bb; ... default: mem_op(..., size); goto merge_bb; } merge_bb: Differential Revision: http://reviews.llvm.org/D28966 llvm-svn: 299446
* SamplePGO ThinLTO ICP fix for local functions.Dehao Chen2017-03-141-0/+11
| | | | | | | | | | | | | | | | | | | | | | | | Summary: In SamplePGO, if the profile is collected from non-LTO binary, and used to drive ThinLTO, the indirect call promotion may fail because ThinLTO adjusts local function names to avoid conflicts. There are two places of where the mismatch can happen: 1. thin-link prepends SourceFileName to front of FuncName to build the GUID (GlobalValue::getGlobalIdentifier). Unlike instrumentation FDO, SamplePGO does not use the PGOFuncName scheme and therefore the indirect call target profile data contains a hash of the OriginalName. 2. backend compiler promotes some local functions to global and appends .llvm.{$ModuleHash} to the end of the FuncName to derive PromotedFunctionName This patch tries at the best effort to find the GUID from the original local function name (in profile), and use that in ICP promotion, and in SamplePGO matching that happens in the backend after importing/inlining: 1. in thin-link, it builds the map from OriginalName to GUID so that when thin-link reads in indirect call target profile (represented by OriginalName), it knows which GUID to import. 2. in backend compiler, if sample profile reader cannot find a profile match for PromotedFunctionName, it will try to find if there is a match for OriginalFunctionName. 3. in backend compiler, we build symbol table entry for OriginalFunctionName and pointer to the same symbol of PromotedFunctionName, so that ICP can find the correct target to promote. Reviewers: mehdi_amini, tejohnson Reviewed By: tejohnson Subscribers: llvm-commits, Prazek Differential Revision: https://reviews.llvm.org/D30754 llvm-svn: 297757
* [PGO] Text format profile reader needs to clear the value profileRong Xu2017-03-031-1/+1
| | | | | | | | | | | | | | | | Summary: Reset the ValueData for each function to avoid using the ones in the previous function. Reviewers: davidxl Reviewed By: davidxl Subscribers: llvm-commits, xur Differential Revision: https://reviews.llvm.org/D30479 llvm-svn: 296916
* [ProfileData] Fix some Clang-tidy modernize and Include What You Use ↵Eugene Zelenko2017-03-039-97/+241
| | | | | | warnings; other minor fixes (NFC). llvm-svn: 296846
* [PGO] Fix a bug in reading text format value profile.Rong Xu2017-02-271-2/+3
| | | | | | | | | | | | | | Summary: Should use the Valuekind read from the profile. Reviewers: davidxl Reviewed By: davidxl Subscribers: llvm-commits, xur Differential Revision: https://reviews.llvm.org/D30420 llvm-svn: 296391
* Fix comments. NFC.Rong Xu2017-02-271-1/+1
| | | | | | Change "Thin-LTO" to "ThinLTO" in the comments for consistency. llvm-svn: 296362
* [PGO] Directory name stripping in global identifier for static functionsRong Xu2017-02-251-1/+34
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Current internal option -static-func-full-module-prefix keeps all the directory path the profile counter names for static functions. The default of this option is false. This strips the directory names from the source filename which is problematic: (1) it creates linker errors for profile-generation compilation, exposed in our internal benchmarks. We are seeing messages like "warning: relocation refers to discarded section". This is due to the name conflicts after the stripping. (2) the stripping only applies to getPGOFuncName. Current Thin-LTO module importing for the indirect-calls assumes the source directory name not being stripped. Current default value for this option can potentially prevent some inter-module indirect-call-promotions. This patch turns the default value for -static-func-full-module-prefix to true. The second part of the patch is to have an alternative implementation under the internal option -static-func-strip-dirname-prefix=<value> This options specifies level of directories to be stripped from the source filename. Using a large value as the parameter has the same effect as -static-func-full-module-prefix. Differential Revision: http://reviews.llvm.org/D29512 llvm-svn: 296206
* Fix an obvious bug in SampleProfileReaderGCC.Dehao Chen2017-02-221-5/+3
| | | | | | | | | | | | | | Summary: The CallTargetProfile should be added to FProfile to be consistent with other profile readers. Reviewers: dnovillo, davidxl Reviewed By: davidxl Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D30233 llvm-svn: 295852
* Cleanup dump() functions.Matthias Braun2017-01-281-1/+7
| | | | | | | | | | | | | | | | | | We had various variants of defining dump() functions in LLVM. Normalize them (this should just consistently implement the things discussed in http://lists.llvm.org/pipermail/cfe-dev/2014-January/034323.html For reference: - Public headers should just declare the dump() method but not use LLVM_DUMP_METHOD or #if !defined(NDEBUG) || defined(LLVM_ENABLE_DUMP) - The definition of a dump method should look like this: #if !defined(NDEBUG) || defined(LLVM_ENABLE_DUMP) LLVM_DUMP_METHOD void MyClass::dump() { // print stuff to dbgs()... } #endif llvm-svn: 293359
* [WebAssembly] Add triple support for the new wasm object formatDan Gohman2017-01-171-1/+1
| | | | | | Differential Revision: https://reviews.llvm.org/D26701 llvm-svn: 292252
* Recommit r292214 "[Support/Compression] - Change zlib API to return Error ↵George Rimar2017-01-171-7/+10
| | | | | | | | | | | | | | | | | | instead of custom status" No any changes, will follow up with D28807 commit containing APLi change for clang to fix build issues happened. Original commit message: [Support/Compression] - Change zlib API to return Error instead of custom status. Previously API returned custom enum values. Patch changes it to return Error with string description. That should help users to report errors in universal way. Differential revision: https://reviews.llvm.org/D28684 llvm-svn: 292226
* Revert r292214 "[Support/Compression] - Change zlib API to return Error ↵George Rimar2017-01-171-10/+7
| | | | | | | | | instead of custom status." It broked clang: http://lab.llvm.org:8080/green//job/clang-stage1-cmake-RA-incremental_build/34218/consoleFull#46141505449ba4694-19c4-4d7e-bec5-911270d8a58c llvm-svn: 292217
* [Support/Compression] - Change zlib API to return Error instead of custom ↵George Rimar2017-01-171-7/+10
| | | | | | | | | | | | status. Previously API returned custom enum values. Patch changes it to return Error with string description. That should help users to report errors in universal way. Differential revision: https://reviews.llvm.org/D28684 llvm-svn: 292214
* Resubmit "[PGO] Turn off comdat renaming in IR PGO by default"Rong Xu2017-01-111-0/+43
| | | | | | This patch resubmits the changes in r291588. llvm-svn: 291696
* Revert "[PGO] Turn off comdat renaming in IR PGO by default"Rong Xu2017-01-101-43/+0
| | | | | | | This patch reverts r291588: [PGO] Turn off comdat renaming in IR PGO by default, as we are seeing some hash mismatches in our internal tests. llvm-svn: 291621
* [PGO] Turn off comdat renaming in IR PGO by defaultRong Xu2017-01-101-0/+43
| | | | | | | | | | | | | | | | | | | | | | | Summary: In IR PGO we append the function hash to comdat functions to avoid the potential hash mismatch. This turns out not legal in some cases: if the comdat function is address-taken and used in comparison. Renaming changes the semantic. This patch turns off comdat renaming by default. To alleviate the hash mismatch issue, we now rename the profile variable for comdat functions. Profile allows co-existing multiple versions of profiles with different hash value. The inlined copy will always has the correct profile counter. The out-of-line copy might not have the correct count. But we will not have the bogus mismatch warning. Reviewers: davidxl Subscribers: llvm-commits, xur Differential Revision: https://reviews.llvm.org/D28416 llvm-svn: 291588
* Make the Error class constructor protectedMehdi Amini2016-11-111-1/+1
| | | | | | | | | This is forcing to use Error::success(), which is in a wide majority of cases a lot more readable. Differential Revision: https://reviews.llvm.org/D26481 llvm-svn: 286561
* Retire llvm::alignOf in favor of C++11 alignof.Benjamin Kramer2016-10-201-1/+1
| | | | | | No functionality change intended. llvm-svn: 284733
* Remove LLVM_NOEXCEPT and replace it with noexceptReid Kleckner2016-10-193-3/+3
| | | | | | | Now that we have dropped MSVC 2013, all supported compilers support noexcept and we can drop this portability macro. llvm-svn: 284672
OpenPOWER on IntegriCloud