Late to this, but LGTM.

Address comment.

Okay added a new test.

Address comment.

In D97592#2593258, @davidxl wrote:

Perhaps add a test case showing that up to 3 ranges can be promoted?

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.