[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
includ

[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

show more ...

[PGO] Revert r255366: solution incomplete, not handling lambda yet

llvm-svn: 255368

[PGO] Stop using invalid char in instr variable names.

(This is part-2 of the patch -- fixing test cases)

Before the patch, -fprofile-instr-generate compile will fail
if no integrated-as is specifi

[PGO] Stop using invalid char in instr variable names.

(This is part-2 of the patch -- fixing test cases)

Before the patch, -fprofile-instr-generate compile will fail
if no integrated-as is specified when the file contains
any static functions (the -S output is also invalid).

This patch fixed the issue. With the change, the index format
version will be bumped up by 1. Backward compatibility is
preserved with this change.

Differential Revision: http://reviews.llvm.org/D15243

llvm-svn: 255366

show more ...

test: Use llvm-profdata merge in Profile tests

In preparation for using a binary format for instrumentation based
profiling, explicitly treat the test inputs as text and transform them
before runnin

test: Use llvm-profdata merge in Profile tests

In preparation for using a binary format for instrumentation based
profiling, explicitly treat the test inputs as text and transform them
before running. This will allow us to leave the checked in files in
human readable format once the instrumentation format is binary.

No functional change.

llvm-svn: 206509

show more ...