maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/clang/test/Profile/Inputs/cxx-throws.proftext

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

27 lines
124 B
Plaintext
Raw Normal View History

CodeGen: Include a function hash in instrumentation based profiling The hash itself is still the number of counters, which isn't all that useful, but this separates the API changes from the actual implementation of the hash and will make it easier to transition to the ProfileData library once it's implemented. llvm-svn: 204186
2014-03-19 05:58:06 +08:00
_Z6throwsv
[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
340120998528097520
CodeGen: Include a function hash in instrumentation based profiling The hash itself is still the number of counters, which isn't all that useful, but this separates the API changes from the actual implementation of the hash and will make it easier to transition to the ProfileData library once it's implemented. llvm-svn: 204186
2014-03-19 05:58:06 +08:00
9
Revert "CodeGen: Use a binary format for instrumentation based profiling" I've clearly done something wrong with how to get this to link correctly. Reverting for now. This reverts commit r203711. llvm-svn: 203712
2014-03-13 05:06:31 +08:00
1
100
100
66
33
17
50
33
100
InstrProf: Mark code regions after throw expressions as unreachable We weren't setting regions as being unreachable after C++ throw expressions, leading to incorrect count propagations. llvm-svn: 235967
2015-04-28 14:31:55 +08:00
_Z11unreachablei
[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
706946049169
InstrProf: Mark code regions after throw expressions as unreachable We weren't setting regions as being unreachable after C++ throw expressions, leading to incorrect count propagations. llvm-svn: 235967
2015-04-28 14:31:55 +08:00
3
CodeGen: Include a function hash in instrumentation based profiling The hash itself is still the number of counters, which isn't all that useful, but this separates the API changes from the actual implementation of the hash and will make it easier to transition to the ProfileData library once it's implemented. llvm-svn: 204186
2014-03-19 05:58:06 +08:00
1
Revert "CodeGen: Use a binary format for instrumentation based profiling" I've clearly done something wrong with how to get this to link correctly. Reverting for now. This reverts commit r203711. llvm-svn: 203712
2014-03-13 05:06:31 +08:00
1
InstrProf: Mark code regions after throw expressions as unreachable We weren't setting regions as being unreachable after C++ throw expressions, leading to incorrect count propagations. llvm-svn: 235967
2015-04-28 14:31:55 +08:00
0
Revert "CodeGen: Use a binary format for instrumentation based profiling" I've clearly done something wrong with how to get this to link correctly. Reverting for now. This reverts commit r203711. llvm-svn: 203712
2014-03-13 05:06:31 +08:00
InstrProf: Mark code regions after throw expressions as unreachable We weren't setting regions as being unreachable after C++ throw expressions, leading to incorrect count propagations. llvm-svn: 235967
2015-04-28 14:31:55 +08:00
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
187765848
InstrProf: Mark code regions after throw expressions as unreachable We weren't setting regions as being unreachable after C++ throw expressions, leading to incorrect count propagations. llvm-svn: 235967
2015-04-28 14:31:55 +08:00
3
1
1
1