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/c-general.proftext

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

170 lines
689 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
simple_loops
[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
1245818015463121
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
4
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
75
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
conditionals
[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
4904767535850050386
[Coverage] Add support for Branch Coverage in LLVM Source-Based Code Coverage This is an enhancement to LLVM Source-Based Code Coverage in clang to track how many times individual branch-generating conditions are taken (evaluate to TRUE) and not taken (evaluate to FALSE). Individual conditions may comprise larger boolean expressions using boolean logical operators. This functionality is very similar to what is supported by GCOV except that it is very closely anchored to the ASTs. Differential Revision: https://reviews.llvm.org/D84467
2020-12-29 01:20:48 +08:00
13
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
50
50
33
33
16
99
100
99
[Coverage] Add support for Branch Coverage in LLVM Source-Based Code Coverage This is an enhancement to LLVM Source-Based Code Coverage in clang to track how many times individual branch-generating conditions are taken (evaluate to TRUE) and not taken (evaluate to FALSE). Individual conditions may comprise larger boolean expressions using boolean logical operators. This functionality is very similar to what is supported by GCOV except that it is very closely anchored to the ASTs. Differential Revision: https://reviews.llvm.org/D84467
2020-12-29 01:20:48 +08:00
99
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
100
[Coverage] Add support for Branch Coverage in LLVM Source-Based Code Coverage This is an enhancement to LLVM Source-Based Code Coverage in clang to track how many times individual branch-generating conditions are taken (evaluate to TRUE) and not taken (evaluate to FALSE). Individual conditions may comprise larger boolean expressions using boolean logical operators. This functionality is very similar to what is supported by GCOV except that it is very closely anchored to the ASTs. Differential Revision: https://reviews.llvm.org/D84467
2020-12-29 01:20:48 +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
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
early_exits
[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
2880354649761471549
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
0
51
1
25
1
25
1
0
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
jumps
[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
15051420506203462683
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
22
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
1
0
1
0
0
1
0
1
2
3
2
0
3
0
1
1
1
10
0
10
9
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
switches
[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
43242458792028222
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
19
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
1
1
15
7
1
0
2
2
3
3
4
4
0
4
4
5
1
0
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
big_switch
[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
13144136522122330070
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
17
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
32
32
1
0
1
1
11
11
1
1
15
15
1
1
2
2
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
boolean_operators
[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
1245693242827665
[Coverage] Add support for Branch Coverage in LLVM Source-Based Code Coverage This is an enhancement to LLVM Source-Based Code Coverage in clang to track how many times individual branch-generating conditions are taken (evaluate to TRUE) and not taken (evaluate to FALSE). Individual conditions may comprise larger boolean expressions using boolean logical operators. This functionality is very similar to what is supported by GCOV except that it is very closely anchored to the ASTs. Differential Revision: https://reviews.llvm.org/D84467
2020-12-29 01:20:48 +08:00
14
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
34
[Coverage] Add support for Branch Coverage in LLVM Source-Based Code Coverage This is an enhancement to LLVM Source-Based Code Coverage in clang to track how many times individual branch-generating conditions are taken (evaluate to TRUE) and not taken (evaluate to FALSE). Individual conditions may comprise larger boolean expressions using boolean logical operators. This functionality is very similar to what is supported by GCOV except that it is very closely anchored to the ASTs. Differential Revision: https://reviews.llvm.org/D84467
2020-12-29 01:20:48 +08:00
1
66
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
66
17
[Coverage] Add support for Branch Coverage in LLVM Source-Based Code Coverage This is an enhancement to LLVM Source-Based Code Coverage in clang to track how many times individual branch-generating conditions are taken (evaluate to TRUE) and not taken (evaluate to FALSE). Individual conditions may comprise larger boolean expressions using boolean logical operators. This functionality is very similar to what is supported by GCOV except that it is very closely anchored to the ASTs. Differential Revision: https://reviews.llvm.org/D84467
2020-12-29 01:20:48 +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
34
[Coverage] Add support for Branch Coverage in LLVM Source-Based Code Coverage This is an enhancement to LLVM Source-Based Code Coverage in clang to track how many times individual branch-generating conditions are taken (evaluate to TRUE) and not taken (evaluate to FALSE). Individual conditions may comprise larger boolean expressions using boolean logical operators. This functionality is very similar to what is supported by GCOV except that it is very closely anchored to the ASTs. Differential Revision: https://reviews.llvm.org/D84467
2020-12-29 01:20:48 +08:00
17
33
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
33
50
[Coverage] Add support for Branch Coverage in LLVM Source-Based Code Coverage This is an enhancement to LLVM Source-Based Code Coverage in clang to track how many times individual branch-generating conditions are taken (evaluate to TRUE) and not taken (evaluate to FALSE). Individual conditions may comprise larger boolean expressions using boolean logical operators. This functionality is very similar to what is supported by GCOV except that it is very closely anchored to the ASTs. Differential Revision: https://reviews.llvm.org/D84467
2020-12-29 01:20:48 +08:00
33
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
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
boolop_loops
[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
12402604614320574815
[Coverage] Add support for Branch Coverage in LLVM Source-Based Code Coverage This is an enhancement to LLVM Source-Based Code Coverage in clang to track how many times individual branch-generating conditions are taken (evaluate to TRUE) and not taken (evaluate to FALSE). Individual conditions may comprise larger boolean expressions using boolean logical operators. This functionality is very similar to what is supported by GCOV except that it is very closely anchored to the ASTs. Differential Revision: https://reviews.llvm.org/D84467
2020-12-29 01:20:48 +08:00
13
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
50
51
50
[Coverage] Add support for Branch Coverage in LLVM Source-Based Code Coverage This is an enhancement to LLVM Source-Based Code Coverage in clang to track how many times individual branch-generating conditions are taken (evaluate to TRUE) and not taken (evaluate to FALSE). Individual conditions may comprise larger boolean expressions using boolean logical operators. This functionality is very similar to what is supported by GCOV except that it is very closely anchored to the ASTs. Differential Revision: https://reviews.llvm.org/D84467
2020-12-29 01:20:48 +08:00
50
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
26
[Coverage] Add support for Branch Coverage in LLVM Source-Based Code Coverage This is an enhancement to LLVM Source-Based Code Coverage in clang to track how many times individual branch-generating conditions are taken (evaluate to TRUE) and not taken (evaluate to FALSE). Individual conditions may comprise larger boolean expressions using boolean logical operators. This functionality is very similar to what is supported by GCOV except that it is very closely anchored to the ASTs. Differential Revision: https://reviews.llvm.org/D84467
2020-12-29 01:20:48 +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
50
51
50
[Coverage] Add support for Branch Coverage in LLVM Source-Based Code Coverage This is an enhancement to LLVM Source-Based Code Coverage in clang to track how many times individual branch-generating conditions are taken (evaluate to TRUE) and not taken (evaluate to FALSE). Individual conditions may comprise larger boolean expressions using boolean logical operators. This functionality is very similar to what is supported by GCOV except that it is very closely anchored to the ASTs. Differential Revision: https://reviews.llvm.org/D84467
2020-12-29 01:20:48 +08:00
50
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
26
[Coverage] Add support for Branch Coverage in LLVM Source-Based Code Coverage This is an enhancement to LLVM Source-Based Code Coverage in clang to track how many times individual branch-generating conditions are taken (evaluate to TRUE) and not taken (evaluate to FALSE). Individual conditions may comprise larger boolean expressions using boolean logical operators. This functionality is very similar to what is supported by GCOV except that it is very closely anchored to the ASTs. Differential Revision: https://reviews.llvm.org/D84467
2020-12-29 01:20:48 +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
CodeGen: Handle binary conditional operators in PGO instrumentation This treats binary conditional operators in the same way as ternary conditional operators for instrumentation based profiling. llvm-svn: 206021
2014-04-11 14:10:10 +08:00
conditional_operator
[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
54992
CodeGen: Handle binary conditional operators in PGO instrumentation This treats binary conditional operators in the same way as ternary conditional operators for instrumentation based profiling. llvm-svn: 206021
2014-04-11 14:10:10 +08:00
3
1
0
1
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
do_fallthrough
[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
8714614136504380050
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
4
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
10
2
8
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
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
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
[PGO] Revert r255366: solution incomplete, not handling lambda yet llvm-svn: 255368
2015-12-12 04:23:12 +08:00
c-general.c:static_func
[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
18129
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
2
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
10