D93281 looks good to me.

I can add "cl::ZeroOrMore" to "-vp-counters-per-site". Would it be good?

In D92669#2437383, @davidxl wrote:

The size increase is significant. It is likely that some very large apps may run into size limit issue at link time with this change.

Adjust only for dynamic linking mode. Rebase.

In D92669#2434247, @davidxl wrote:

how much size increase is in clang instrumented build?

Address comment.

https://reviews.llvm.org/D92669 should fix the issue.

Uploaded https://reviews.llvm.org/D92599

Hi, we encountered this issue https://bugs.llvm.org/show_bug.cgi?id=48055 which reverting this patch seems to make it go away.

This is with clang trying to PGO itself. Build with -DLLVM_BUILD_INSTRUMENTED=IR -DLLVM_BUILD_RUNTIME=No and use the result to build the LLVM tree again.

https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=318445929&repo=ash&lineNumber=17322

In D81682#2328239, @dmajor wrote:

In D81682#2168134, @yamauchi wrote:

In D81682#2168028, @dmajor wrote:

The re-landing of this patch in 4a539faf74b9b4c25ee3b880e4007564bd5139b0 causes our PGO build of clang to have thousands of

LLVM Profile Warning: Unable to track new values: Running out of static counters.  Consider using option -mllvm -vp-counters-per-site=<n> to allocate more value profile counters at compile time.

Is that expected? Should the cmake set a higher value of -vp-counters-per-site in self-hosted PGO builds?

This has been reverted for now. There was a related issue.

Our build bots still show lots of this warning, is that expected?

Update the patch description.

I'm not familiar with the history of this file well, but I had the same impression: it'd be nice if there's a single copy but since compiler-rt is set up to build without depending on llvm/, it's in the way it is currently.

Rebase.

Address comment.

In D87337#2262611, @lebedev.ri wrote:

As per https://llvm.org/docs/LangRef.html, deopt term appears to be already coined.

I think this was reverted by https://reviews.llvm.org/rG7bfaa40086359ed7e41c862ab0a65e0bb1be0aeb

Address comments.

Update to remove the getZExtOrTrunc.

In D85784#2211641, @davidxl wrote:

If shouldOptimizeForSize is not available for loop analysis, should the check of be removed unconditionally instead of gated upon whether there is a hint?

In D85989#2218934, @craig.topper wrote:

Is there another patch coming to call hasFSRM()?

In D85784#2211641, @davidxl wrote:

If shouldOptimizeForSize is not available for loop analysis, should the check of be removed unconditionally instead of gated upon whether there is a hint?

In D84782#2191243, @MaskRay wrote:

@yamauchi Do we need cd890944ad344b1b8cac58332ab11c9eec6b61e9 and 3d6f53018f845e893ad34f64ff2851a2e5c3ba1d in https://github.com/llvm/llvm-project/tree/release/11.x ?

In D84953#2185239, @davidxl wrote:

I think the test should use profile-gen option to compare generated hash of otherwise identical functions (except for memop).

Address comment. Use -pgo-instr-gen.

Yup, -pgo-instr-old-cfg-hashing=true to revert back to the old hashing.

Latest update diff:

Use endian::write64le.

Here's the diff in the latest update:

Fix the endianness issue.

Builtbot failure: http://lab.llvm.org:8011/builders/clang-ppc64be-linux/builds/51984

Address comments. PTAL.

Address comment.

Rebase past D84865.

In D84782#2180626, @davidxl wrote:

changes like in llvm/test/Transforms/PGOProfile/PR41279.ll etc can be independently committed.

Address comment.

In D84782#2180578, @davidxl wrote:

Can you split out the test changes and commit it separately?

Rebase (converting one more test) and fixing a typo and whitespace.

In D84782#2180432, @davidxl wrote:

On version bump --- looks like FrontPGO has been bumping version for hashing changes while IR PGO had not, so it is ok to leave the version unchanged (current situation is also confusing as the version of IR and FE PGO are mixed).

On the other hand, just in case, we need to introduce a temporary internal option for people to be able to keep on using old profile (with older scheme of hashing) for a while. Basically, under the option, the hashing scheme falls back to the old way.

other than that, looks fine.

Add a flag to back out to the old hashing.

Many tests can also be enhanced to filter out the hash details if they are not part the main test.

Shift the higher 32 bits by 28 bits and add.