llvm-project/clang/test/Profile/Inputs/gcc-flag-compatibility.prof...

main
1160280
2
1
100
Add GCC-compatible flags -fprofile-generate and -fprofile-use. This patch adds support for specifying where the profile is emitted in a way similar to GCC. These flags are used to specify directories instead of filenames. When -fprofile-generate=DIR is used, the compiler will generate code to write to <DIR>/default.profraw. The patch also adds a couple of extensions: LLVM_PROFILE_FILE can still be used to override the directory and file name to use and -fprofile-use accepts both directories and filenames. To simplify the set of flags used in the backend, all the flags get canonicalized to -fprofile-instr-{generate,use} when passed to the backend. The decision to use a default name for the profile is done in the driver. llvm-svn: 241825 2015-07-10 01:23:53 +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			`1160280`
Add GCC-compatible flags -fprofile-generate and -fprofile-use. This patch adds support for specifying where the profile is emitted in a way similar to GCC. These flags are used to specify directories instead of filenames. When -fprofile-generate=DIR is used, the compiler will generate code to write to <DIR>/default.profraw. The patch also adds a couple of extensions: LLVM_PROFILE_FILE can still be used to override the directory and file name to use and -fprofile-use accepts both directories and filenames. To simplify the set of flags used in the backend, all the flags get canonicalized to -fprofile-instr-{generate,use} when passed to the backend. The decision to use a default name for the profile is done in the driver. llvm-svn: 241825 2015-07-10 01:23:53 +08:00			`2`
			`1`
			`100`