aboutsummaryrefslogtreecommitdiff
path: root/llvm/unittests/ProfileData/InstrProfTest.cpp
AgeCommit message (Collapse)AuthorFilesLines
2023-12-18[PGO][GlobalValue][LTO]In GlobalValues::getGlobalIdentifier, use semicolon ↵Mingming Liu1-2/+2
as delimiter for local-linkage varibles. (#74008) Commit fe05193 (phab D156569), IRPGO names uses format `[<filepath>;]<linkage-name>` while prior format is `[<filepath>:<mangled-name>`. The format change would break the use case demonstrated in (updated) `llvm/test/Transforms/PGOProfile/thinlto_indirect_call_promotion.ll` and `compiler-rt/test/profile/instrprof-thinlto-indirect-call-promotion.cpp` This patch changes `GlobalValues::getGlobalIdentifer` to use the semicolon. To elaborate on the scenario how things break without this PR 1. IRPGO raw profiles stores (compressed) IRPGO names of functions in one section, and per-function profile data in another section. The [NameRef](https://github.com/llvm/llvm-project/blob/fc715e4cd942612a091097339841733757b53824/compiler-rt/include/profile/InstrProfData.inc#L72) field in per-function profile data is the MD5 hash of IRPGO names. 2. When raw profiles are converted to indexed format profiles, the profiled address is [mapped](https://github.com/llvm/llvm-project/blob/fc715e4cd942612a091097339841733757b53824/llvm/lib/ProfileData/InstrProf.cpp#L876-L885) to the MD5 hash of the callee. 3. In `pgo-instr-use` thin-lto prelink pipeline, MD5 hash of IRPGO names will be [annotated](https://github.com/llvm/llvm-project/blob/fc715e4cd942612a091097339841733757b53824/llvm/lib/Transforms/Instrumentation/PGOInstrumentation.cpp#L1707) as value profiles, and used to import indirect-call-prom candidates. If the annotated MD5 hash is computed from the new format while import uses the prior format, the callee cannot be imported. *`compiler-rt/test/profile/instrprof-thinlto-indirect-call-promotion.cpp` is added to have an end-to-end test. * `llvm/test/Transforms/PGOProfile/thinlto_indirect_call_promotion.ll` is updated to have better test coverage from another aspect (as runtime tests are more sensitive to the environment and may be skipped by some contributors)
2023-11-22[nfc][InstrProfTest]Parameterize the edge cases of value profile merge by ↵Mingming Liu1-31/+47
value kind (#73165) There are three test cases to test the merge of value profiles. 'get_icall_data_merge1' tests the basic case; {get_icall_data_merge1_saturation, get_icall_data_merge_site_trunc} tests the edge case. This patch parameterizes the edge case test coverage by value kind and adds the coverage of 'IPVK_MemOPSize'. Keep the basic test structure as it is. The main reason is test data construction and test assertions is clearer for each kind in the basic test. - Using a loop for different value kinds in one test case doesn't work very well. The instr-prof-writer is stateful (e.g., keeps track of per-function profile data in a [container](https://github.com/llvm/llvm-project/blob/a9c149df7666bb2f8755794b97573134e5cfeb38/llvm/include/llvm/ProfileData/InstrProfWriter.h#L43))
2023-11-21[nfc][InstrProfTest]Add a test fixture to parameterize the read-write test ↵Mingming Liu1-104/+49
of value profiles (#73038) This patch factor out the common code among three similar test cases. The input data and test logic are pretty similar. Parameterize the differences (prof-weight and endianness) as advised in https://github.com/llvm/llvm-project/pull/72611. - Remove duplicated tests
2023-11-21[nfc][InstrProfTest]Un-parameterize test cases that doesn't use profile ↵Mingming Liu1-7/+6
reader and writer (#73026) Test fixture `MaybeSparseInstrProfTest` parameterize InstrProfWriter by whether output is sparse or not. This test fixture has 20 test cases, and 6 of them doesn't use profile reader and writer. Undo the parameterization for these test cases will reduce redundant tests. This is one clean-up PR. (A few more clean-ups to come soon, but they are not inter-dependent)
2023-11-20Revert "[nfc][InstrProfTest]Factor out common code for value profile test" ↵Mingming Liu1-129/+145
(#72921) Reverts llvm/llvm-project#72611 for more follow-up discussions
2023-11-20[nfc][InstrProfTest]Factor out common code for value profile test (#72611)Mingming Liu1-145/+129
Three existing test cases {get_icall_data_read_write, get_icall_data_read_write_with_weight,get_icall_data_read_write_big_endian} have common test data and testing logic. Extract common code into `testICallDataReadWrite`. - Add helper function `addValueProfData` and `testValueDataArray`. This two helper functions are used by `testICallDataReadWrite`, and possibly other test cases.
2023-10-26[NFC] In InstrProf, generalize helper functions to take 'GlobalObject'. They ↵Mingming Liu1-2/+2
currently take 'Functions' as function parameters or have 'Func' in the name. (#70287) - For instance, `collectPGOFuncNameStrings` is reused a lot in https://github.com/llvm/llvm-project/pull/66825 to get the compressed vtable names; and in some added callsites it's just confusing to see 'func' since context clearly shows it's not. This function currently just takes a list of strings as input so name it to `collectGlobalObjectNameStrings` - Do the rename in a standalone patch since the method is used in non-llvm codebase. It's easier to rollback this NFC in case rename in that codebase takes longer.
2023-10-12Use llvm::endianness::{big,little,native} (NFC)Kazu Hirata1-3/+3
Note that llvm::support::endianness has been renamed to llvm::endianness while becoming an enum class as opposed to an enum. This patch replaces support::{big,little,native} with llvm::endianness::{big,little,native}.
2023-10-04[NFC]Rename InstrProf::getFuncName{,orExternalSymbol} to ↵Mingming Liu1-22/+24
getFuncOrValName{,IfDefined} (#68240) - This function looks up MD5ToNameMap to return a name for a given MD5. https://github.com/llvm/llvm-project/pull/66825 adds MD5 of global variable names into this map. So rename methods and update comments
2023-08-07[InstrProf] Encode linkage names in IRPGO counter namesEllis Hoag1-6/+126
Prior to this diff, names in the `__llvm_prf_names` section had the format `[<filepath>:]<function-name>`, e.g., `main.cpp:foo`, `bar`. `<filepath>` is used to discriminate between possibly identical function names when linkage is local and `<function-name>` simply comes from `F.getName()`. This has two problems: * `:` is commonly found in Objective-C functions so that names like `main.mm:-[C foo::]` and `-[C bar::]` are difficult to parse * `<function-name>` might be different from the linkage name, so it cannot be used to pass a function order to the linker via `-symbol-ordering-file` or `-order_file` (see https://discourse.llvm.org/t/rfc-temporal-profiling-extension-for-irpgo/68068) Instead, this diff changes the format to `[<filepath>;]<linkage-name>`, e.g., `main.cpp;_foo`, `_bar`. The hope is that `;` won't realistically be found in either `<filepath>` or `<linkage-name>`. To prevent invalidating all prior IRPGO profiles, we also lookup the prior name format when a record is not found (see `InstrProfSymtab::create()`, `readMemprof()`, and `getInstrProfRecord()`). It seems that Swift and Clang FE-PGO rely on the original `getPGOFuncName()`, so we cannot simply replace it. Reviewed By: MaskRay Differential Revision: https://reviews.llvm.org/D156569
2023-04-28[PGO] Fix expensive test compilation errorChristian Ulmann1-4/+6
This commit fixes a compilation error introduced in https://reviews.llvm.org/D149361 Reviewed By: gysit Differential Revision: https://reviews.llvm.org/D149434
2023-04-27[profiling] Improve error message for raw profile header mismatchesJessica Paquette1-1/+3
When a user uses a mismatched clang + llvm-profdata, they didn't get a very informative error message. It would just say "unsupported version". As a result, users are often confused as to what they are supposed to do and tend to assume that it's a bug in the profiling runtime. This patch improves the error message by: - Adding a new class of error (`raw_profile_version_mismatch`) to make it clear that, specifically, the *raw profile* version is unsupported because of a tool mismatch. - Adding an error message that tells the user which raw profile version was encountered, which version was expected, and instructs them to align their tool versions. To support this, this patch also updates `InstrProfError::take` to also propagate the optional error message. Differential Revision: https://reviews.llvm.org/D149361
2023-04-13Fix warnings in InstrProfTest.cppEllis Hoag1-4/+5
The warnings were introduced in https://reviews.llvm.org/D148150 Reviewed By: snehasish Differential Revision: https://reviews.llvm.org/D148259
2023-04-13[InstrProf][Temporal] Add weight field to tracesEllis Hoag1-16/+32
As discussed in [0], add a `weight` field to temporal profiling traces found in profiles. This allows users to use the `--weighted-input=` flag in the `llvm-profdata merge` command to weight traces from different scenarios differently. Note that this is a breaking change, but since [1] landed very recently and there is no way to "use" this trace data, there should be no users of this feature. We believe it is acceptable to land this change without bumping the profile format version. [0] https://reviews.llvm.org/D147812#4259507 [1] https://reviews.llvm.org/D147287 Reviewed By: snehasish Differential Revision: https://reviews.llvm.org/D148150
2023-04-11[InstrProf] Temporal ProfilingEllis Hoag1-2/+84
As described in [0], this extends IRPGO to support //Temporal Profiling//. When `-pgo-temporal-instrumentation` is used we add the `llvm.instrprof.timestamp()` intrinsic to the entry of functions which in turn gets lowered to a call to the compiler-rt function `INSTR_PROF_PROFILE_SET_TIMESTAMP()`. A new field in the `llvm_prf_cnts` section stores each function's timestamp. Then in `llvm-profdata merge` we convert these function timestamps into a //trace// and add it to the indexed profile. Since these traces could significantly increase the profile size, we've added `-max-temporal-profile-trace-length` and `-temporal-profile-trace-reservoir-size` to limit the length of a trace and the number of traces in a profile, respectively. In a future diff we plan to use these traces to construct an optimized function order to reduce the number of page faults during startup. Special thanks to Julian Mestre for helping with reservoir sampling. [0] https://discourse.llvm.org/t/rfc-temporal-profiling-extension-for-irpgo/68068 Reviewed By: snehasish Differential Revision: https://reviews.llvm.org/D147287
2023-01-25[unittests] Use GTEST_SKIP() instead of return when appropriatePaul Robinson1-2/+2
Basically NFC: A TEST/TEST_F/etc that bails out early (usually because setup failed or some other runtime condition wasn't met) generally should use GTEST_SKIP() to report its status correctly, unless it takes steps to report another status (e.g., FAIL()). I did see a handful of tests show up as SKIPPED after this change, which is not unexpected. The status seemed appropriate in all the new cases.
2023-01-05Move from llvm::makeArrayRef to ArrayRef deduction guides - llvm/ partserge-sans-paille1-1/+1
Use deduction guides instead of helper functions. The only non-automatic changes have been: 1. ArrayRef(some_uint8_pointer, 0) needs to be changed into ArrayRef(some_uint8_pointer, (size_t)0) to avoid an ambiguous call with ArrayRef((uint8_t*), (uint8_t*)) 2. CVSymbol sym(makeArrayRef(symStorage)); needed to be rewritten as CVSymbol sym{ArrayRef(symStorage)}; otherwise the compiler is confused and thinks we have a (bad) function prototype. There was a few similar situation across the codebase. 3. ADL doesn't seem to work the same for deduction-guides and functions, so at some point the llvm namespace must be explicitly stated. 4. The "reference mode" of makeArrayRef(ArrayRef<T> &) that acts as no-op is not supported (a constructor cannot achieve that). Per reviewers' comment, some useless makeArrayRef have been removed in the process. This is a follow-up to https://reviews.llvm.org/D140896 that introduced the deduction guides. Differential Revision: https://reviews.llvm.org/D140955
2022-11-26[llvm] Use std::size (NFC)Kazu Hirata1-1/+1
std::size, introduced in C++17, allows us to directly obtain the number of elements of an array.
2022-08-29[llvm-profdata] Improve profile supplementationRong Xu1-5/+6
Current implementation promotes a non-cold function in the SampleFDO profile into a hot function in the FDO profile. This is too aggressive. This patch promotes a hot functions in the SampleFDO profile into a hot function, and a warm function in SampleFDO into a warm function in FDO. Differential Revision: https://reviews.llvm.org/D132601
2022-08-07[llvm] LLVM_NODISCARD => [[nodiscard]]. NFCFangrui Song1-1/+1
With C++17 there is no Clang pedantic warning.
2022-07-08[NFC] Refactor llvm::zlib namespaceCole Kissane1-2/+4
* Refactor compression namespaces across the project, making way for a possible introduction of alternatives to zlib compression. Changes are as follows: * Relocate the `llvm::zlib` namespace to `llvm::compression::zlib`. Reviewed By: MaskRay, leonardchan, phosek Differential Revision: https://reviews.llvm.org/D128953
2022-05-04[memprof] Use unknown_function error type for missing functionsTeresa Johnson1-1/+8
Switch the error type when a function is not found in the memprof profile to unknown_function. This gives compatibility with normal PGO function matching, and also prevents issuing large numbers of additional matching errors since pgo-warn-missing-function is off by default. Differential Revision: https://reviews.llvm.org/D124953
2022-04-08[memprof] Deduplicate and outline frame storage in the memprof profile.Snehasish Kumar1-28/+141
The current implementation of memprof information in the indexed profile format stores the representation of each calling context fram inline. This patch uses an interned representation where the frame contents are stored in a separate on-disk hash table. The table is indexed via a hash of the contents of the frame. With this patch, the compressed size of a large memprof profile reduces by ~22%. Reviewed By: tejohnson Differential Revision: https://reviews.llvm.org/D123094
2022-03-22Reland "[memprof] Store callsite metadata with memprof records."Snehasish Kumar1-22/+40
This reverts commit f4b794427e8037a4e952cacdfe7201e961f31a6f. Reland with underlying msan issue fixed in D122260.
2022-03-21Revert "[memprof] Store callsite metadata with memprof records."Mitch Phillips1-40/+22
This reverts commit 0d362c90d335509c57c0fbd01ae1829e2b9c3765. Reason: Causes the MSan buildbot to fail (see comments on https://reviews.llvm.org/D121179 for more information
2022-03-21[memprof] Store callsite metadata with memprof records.Snehasish Kumar1-22/+40
To ease profile annotation, each of the callsites in a function can be annotated with profile data - "IR metadata format for MemProf" [1]. This patch extends the on-disk serialized record format to store the debug information for allocation callsites incl inline frames. This change is incompatible with the existing format i.e. indexed profiles must be regenerated, raw profiles are unaffected. [1] https://groups.google.com/g/llvm-dev/c/aWHsdMxKAfE/m/WtEmRqyhAgAJ Reviewed By: tejohnson Differential Revision: https://reviews.llvm.org/D121179
2022-02-17Reland "[memprof] Extend the index prof format to include memory profiles."Snehasish Kumar1-0/+62
This patch adds support for optional memory profile information to be included with and indexed profile. The indexed profile header adds a new field which points to the offset of the memory profile section (if present) in the indexed profile. For users who do not utilize this feature the only overhead is a 64-bit offset in the header. The memory profile section contains (1) profile metadata describing the information recorded for each entry (2) an on-disk hashtable containing the profile records indexed via llvm::md5(function_name). We chose to introduce a separate hash table instead of the existing one since the indexing for the instrumented fdo hash table is based on a CFG hash which itself is perturbed by memprof instrumentation. This commit also includes the changes reviewed separately in D120093. Differential Revision: https://reviews.llvm.org/D120103
2022-02-17Revert "Reland "[memprof] Extend the index prof format to include memory ↵Snehasish Kumar1-62/+0
profiles."" This reverts commit 807ba7aace188ada83ddb4477265728e97346af1.
2022-02-17Reland "[memprof] Extend the index prof format to include memory profiles."Snehasish Kumar1-0/+62
This reverts commit 85355a560a33897453df2ef959e255ee725eebce. This patch adds support for optional memory profile information to be included with and indexed profile. The indexed profile header adds a new field which points to the offset of the memory profile section (if present) in the indexed profile. For users who do not utilize this feature the only overhead is a 64-bit offset in the header. The memory profile section contains (1) profile metadata describing the information recorded for each entry (2) an on-disk hashtable containing the profile records indexed via llvm::md5(function_name). We chose to introduce a separate hash table instead of the existing one since the indexing for the instrumented fdo hash table is based on a CFG hash which itself is perturbed by memprof instrumentation. Differential Revision: https://reviews.llvm.org/D118653
2022-02-14Revert "Reland "[memprof] Extend the index prof format to include memory ↵Snehasish Kumar1-62/+0
profiles."" This reverts commit de54e4ab78ef09b60f870e8df6f8a87e56d6bd94 [1/4]
2022-02-14Reland "[memprof] Extend the index prof format to include memory profiles."Snehasish Kumar1-0/+62
This reverts commit 0f73fb18ca333e38cdb9ffa701a8db026c56041d. Use llvm/Profile/MIBEntryDef.inc instead of relative path. Generated the raw profile data with `-mllvm -enable-name-compression=false` so that builbots where the reader is built without zlib do not fail. Also updated the test build instructions.
2022-02-14Revert "[memprof] Extend the index prof format to include memory profiles."Snehasish Kumar1-62/+0
This reverts commit 43c2348c5b926df6bdbc5b70efaa35ecdefe12d5. Buildbots are failing with an error on reading memprof testdata. "Inputs/basic.profraw: profile uses zlib compression but the profile reader was built without zlib support" https://lab.llvm.org/buildbot/#/builders/16/builds/24490
2022-02-14[memprof] Extend the index prof format to include memory profiles.Snehasish Kumar1-0/+62
This patch adds support for optional memory profile information to be included with and indexed profile. The indexed profile header adds a new field which points to the offset of the memory profile section (if present) in the indexed profile. For users who do not utilize this feature the only overhead is a 64-bit offset in the header. The memory profile section contains (1) profile metadata describing the information recorded for each entry (2) an on-disk hashtable containing the profile records indexed via llvm::md5(function_name). We chose to introduce a separate hash table instead of the existing one since the indexing for the instrumented fdo hash table is based on a CFG hash which itself is perturbed by memprof instrumentation. Differential Revision: https://reviews.llvm.org/D118653
2021-10-29[NFC] ProfileSummary: const most of the fields.Mircea Trofin1-1/+1
This simplifies readability / maintainability.
2021-05-14Bump googletest to 1.10.0Benjamin Kramer1-2/+2
2020-07-17[llvm][NFC] Add missing 'override's in unittests/Logan Smith1-3/+3
2019-08-15[llvm] Migrate llvm::make_unique to std::make_uniqueJonas Devlieghere1-1/+1
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. llvm-svn: 369013
2019-07-09[Profile] Support raw/indexed profiles larger than 4GBVedant Kumar1-0/+21
rdar://45955976 llvm-svn: 365565
2019-02-28[PGO] Context sensitive PGO (part 2)Rong Xu1-4/+4
Part 2 of CSPGO changes (mostly related to ProfileSummary). Note that I use a default parameter in setProfileSummary() and getSummary(). This is to break the dependency in clang. I will make the parameter explicit after changing clang in a separated patch. Differential Revision: https://reviews.llvm.org/D54175 llvm-svn: 355131
2019-01-19Update the file headers across all of the LLVM projects in the monorepoChandler Carruth1-4/+3
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
2018-10-10Support for remapping profile data when symbols change, forRichard Smith1-2/+42
instrumentation-based profiling. Reviewers: davidxl, tejohnson, dlj, erik.pilkington Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D51247 llvm-svn: 344184
2018-04-07[unittests] Change std::sort to llvm::sort in response to r327219Mandeep Singh Grang1-5/+5
r327219 added wrappers to std::sort which randomly shuffle the container before sorting. This will help in uncovering non-determinism caused due to undefined sorting order of objects having the same key. To make use of that infrastructure we need to invoke llvm::sort instead of std::sort. Note: This patch is one of a series of patches to replace *all* std::sort to llvm::sort. Refer the comments section in D44363 for a list of all the required patches. llvm-svn: 329475
2018-03-22Revert "Revert "[InstrProf] Support for external functions in text format.""Mircea Trofin1-3/+0
Summary: This reverts commit 364eb09576a7667bc6d3ff80c52a83014ccac976 and separates out the portion that was fixing binary reader error propagation - turns out, there are production cases where that causes a regression. Will re-introduce the error propagation fix separately. The fix to the text reader error propagation is still "in". Reviewers: bkramer Reviewed By: bkramer Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D44807 llvm-svn: 328244
2018-03-22Revert "[InstrProf] Support for external functions in text format."Benjamin Kramer1-0/+3
This reverts commit r328132. Breaks FDO selfhost. I'm seeing error: /tmp/profraw: Invalid instrumentation profile data (bad magic) llvm-svn: 328207
2018-03-21[InstrProf] Encapsulates access to AddrToMD5Map.Mircea Trofin1-1/+1
Summary: This fixes a unittest failure introduced by D44717 D44717 introduced lazy sorting of the internal data structures of the symbol table. The AddrToMD5Map getter was potentially exposing inconsistent (unsorted) state. We could sort in the accessor, however, a client may store the pointer and thus bypass the internal state management of the symbol table. The alternative in this CL blocks direct access to the state, thus ensuring consistent externally-observable state. Reviewers: davidxl, xur, eraman Reviewed By: xur Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D44757 llvm-svn: 328163
2018-03-21[InstrProf] Support for external functions in text format.Mircea Trofin1-3/+0
Summary: External functions appearing as indirect call targets could not be found in the SymTab, and the value:counter record was represented, in the text format, using an empty string for the name. This would then cause a silent parsing error when reading. This CL: - adds explicit support for such functions - fixes the places where we would not propagate errors when reading - addresses a performance issue due to eager resorting of the SymTab. Reviewers: xur, eraman, davidxl Reviewed By: davidxl Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D44717 llvm-svn: 328132
2017-07-10InstrProf: Fix unit test which accidentally used a duplicate nameVedant Kumar1-4/+1
This unit test constructed some profile records incorrectly. One of the records had a duplicate name: adding that record into the writer caused an error unrelated to what needed to be tested. Reported by David Blaikie! llvm-svn: 307596
2017-07-10llvm-profdata: Reduce memory usage by using Error callback rather than memberDavid Blaikie1-66/+70
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
2017-07-07ProfData: Fix some unchecked Errors in unit testsDavid Blaikie1-82/+92
The 'NoError' function was meant to be used as the input to ASSERT/EXPECT_TRUE, but it is easy to forget this (it could be annotated with nodiscard to help this) so many sites that look like they're checked are not (& silently discard the failure). Only one site actually has an Error sneaking out this way and I've replaced that one with a FIXME+consumeError. The rest of the code has been modified to use the EXPECT_THAT_ERROR macros Zach introduced a while back. Between the options available this seems OK/good/something to standardize on - though it's difficult to build a matcher that could handle checking for a specific llvm::Error result, so those remain using the custom ErrorEquals (& the nodiscard added to ensure it is not misused as it was previous to this patch). It could still be generalized a bit further (even not as far as a matcher, but at least support multiple kinds of Error, etc) & added to the general Error utility header. llvm-svn: 307440
2017-07-06Prototype: Reduce llvm-profdata merge memory usage furtherDavid Blaikie1-14/+14
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
generated by cgit v1.1 at 2025-09-29 13:46:19 +0000