llvm-project/clang/test/Profile/Inputs/cxx-rangefor.proftext

_Z9range_forv
8789831523895825398
5
1
4
1
1
1

main
24
1
1
InstrProf: Fix handling of profile counters in the body of range based for We were assigning the counter for the body of the loop to the loop variable initialization for some reason here, but our tests completely lacked coverage for range-for loops. This fixes that and makes the logic generally more similar to the logic for a regular for. llvm-svn: 236277 2015-05-01 06:58:28 +08:00			`_Z9range_forv`
[PGO] Fix computation of function Hash And bump its version number accordingly. This is a patched recommit of 7c298c104bfe725d4315926a656263e8a5ac3054 Previous hash implementation was incorrectly passing an uint64_t, that got converted to an uint8_t, to finalize the hash computation. This led to different functions having the same hash if they only differ by the remaining statements, which is incorrect. Added a new test case that trivially tests that a small function change is reflected in the hash value. Not that as this patch fixes the hash computation, it would invalidate all hashes computed before that patch applies, this is why we bumped the version number. Update profile data hash entries due to hash function update, except for binary version, in which case we keep the buggy behavior for backward compatibility. Differential Revision: https://reviews.llvm.org/D79961 2020-05-26 02:44:35 +08:00			`8789831523895825398`
InstrProf: Fix handling of profile counters in the body of range based for We were assigning the counter for the body of the loop to the loop variable initialization for some reason here, but our tests completely lacked coverage for range-for loops. This fixes that and makes the logic generally more similar to the logic for a regular for. llvm-svn: 236277 2015-05-01 06:58:28 +08:00			`5`
			`1`
			`4`
			`1`
			`1`
			`1`

			`main`
[PGO] Detect more structural changes with the stable hash 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 2017-11-15 07:56:53 +08:00			`24`
InstrProf: Fix handling of profile counters in the body of range based for We were assigning the counter for the body of the loop to the loop variable initialization for some reason here, but our tests completely lacked coverage for range-for loops. This fixes that and makes the logic generally more similar to the logic for a regular for. llvm-svn: 236277 2015-05-01 06:58:28 +08:00			`1`
			`1`