6186971a4a
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
|
||
|---|---|---|
| .. | ||
| Inputs | ||
| README | ||
| c-avoid-direct-call.c | ||
| c-captured.c | ||
| c-counter-overflows.c | ||
| c-general.c | ||
| c-generate.c | ||
| c-indirect-call.c | ||
| c-linkage-available_externally.c | ||
| c-linkage.c | ||
| c-outdated-data.c | ||
| c-ternary.c | ||
| c-unprofiled-blocks.c | ||
| c-unprofiled.c | ||
| c-unreachable-after-switch.c | ||
| cxx-class.cpp | ||
| cxx-hash-v2.cpp | ||
| cxx-implicit.cpp | ||
| cxx-indirect-call.cpp | ||
| cxx-lambda.cpp | ||
| cxx-linkage.cpp | ||
| cxx-missing-bodies.cpp | ||
| cxx-rangefor.cpp | ||
| cxx-stmt-initializers.cpp | ||
| cxx-structors.cpp | ||
| cxx-templates.cpp | ||
| cxx-throws.cpp | ||
| cxx-virtual-destructor-calls.cpp | ||
| def-assignop.cpp | ||
| def-ctors.cpp | ||
| def-dtors.cpp | ||
| func-entry.c | ||
| gcc-flag-compatibility.c | ||
| objc-general.m | ||
| profile-does-not-exist.c | ||
| profile-summary.c | ||
README
These are tests for instrumentation based profiling. This specifically means the -fprofile-instr-generate and -fprofile-instr-use driver flags. Tests in this directory should usually test both: - the generation of instrumentation (-fprofile-instr-generate), and - the use of profile data from instrumented runs (-fprofile-instr-use). In order to test -fprofile-instr-use without actually running an instrumented program, .profdata files are checked into Inputs/. The input source files must include a main function such that building with -fprofile-instr-generate and running the resulting program generates the same .profdata file that is consumed by the tests for -fprofile-instr-use. Even tests that only check -fprofile-instr-use should include such a main function, so that profile data can be regenerated as the .profdata file format evolves.