Thanks. Another suggestion about comment. Other than that, LGTM.

LGTM. Thanks.

I see. Thanks for the explanation.

Commit the fix for the second problem in D84997 together with the assertion and testcase in this patch, so D84997 can be dedicated to solve the other problem.

The multiple inline instance copies generated from loop unrolling or jump threading should have their own FunctionSamples objects. Why merging multiple inline instance to the outline profile will trigger assertion? Could you have a testcase for it?

It's a slightly difference case. In the training build, we didn't unroll, so there's a single inline site in the loop, but in the PGO optimizing build, the loop got unrolled with call site duplicated. And the duplicated call sites all point to the same FunctionSamples, in which case we should merge them only once. Agree that we should add a test case.

In D84997#2186522, @wmi wrote:

Yes, the fix in D84997 is more concise. Here I use a straightforward fix. It is ok for Hongtao to commit D84997, but just add a testcase (free to use the one here).

Yes, the fix in D84997 is more concise. Here I use a straightforward fix. It is ok for Hongtao to commit D84997, but just add a testcase (free to use the one here).

Yes, the fix in D84997 is more concise. Here I use a straightforward fix. It is ok for Hongtao to commit D84997, but just add a testcase (free to use the one here).

The multiple inline instance copies generated from loop unrolling or jump threading should have their own FunctionSamples objects. Why merging multiple inline instance to the outline profile will trigger assertion? Could you have a testcase for it?

Thanks for the work. It is a very useful feature.

Address David's comments.

Address David's comment

I think this feature should be decoupled from the version change -- since this is an approximate anyway. One way to do this is to use max count or total count as a reference point and compute the scale factor.

I also plan to dump the functions cold in instr profile and hot in sample profile, and sort the output according to hotness in sample profile. That can be used to guide PGO users if they want to improve the representativeness of their loadtest. I leave that part in a separate patch for easier review.

LGTM. Better wait another day to see if other reviewers have further comments.

Thanks for the explanation.

In D83743#2150725, @wenlei wrote:

In D83743#2150703, @davidxl wrote:

Can this be extended to the SCC inliner?

Yes, we can use it in SCC inliner as well. We just need extra plumbing there. We can do that in a separate change if needed.

Address David's comments.

In D79978#2141959, @MaskRay wrote:

In D79978#2141768, @wmi wrote:

In D79978#2140849, @MaskRay wrote:

I haven't looked into the details, but the test suggests that the patch is wrong:

# basic-block-sections-cfi-1.ll
        .section        .text,"ax",@progbits,unique,2
_Z2f3b.2:                               # %if.end
        .cfi_startproc
        .cfi_def_cfa %rbp, 16    # this should be inserted after addq $16, %rsp
        .cfi_offset %rbp, -16    # this should be after .cfi_def_cfa %rbp, 16
        addq    $16, %rsp
        popq    %rbp
        .cfi_def_cfa %rsp, 8
        retq

I think the position where the cfi directives are currently inserted is correct. Those directives at the beginning of BB are not to maintain call frame information for instructions inside of BB like "addq $16, %rsp" and "popq %rbp", but to setup the call frame information correctly at the beginning of BB because the BB could be moved around.

Ack. Then what instructions should be placed at the top of these basic blocks? Should .cfi_def_cfa_register %rbp be placed as well? If you move these basic blocks around, .cfi_def_cfa_register %rbp is currently not tracked.

In D79978#2140849, @MaskRay wrote:

I haven't looked into the details, but the test suggests that the patch is wrong:

# basic-block-sections-cfi-1.ll
        .section        .text,"ax",@progbits,unique,2
_Z2f3b.2:                               # %if.end
        .cfi_startproc
        .cfi_def_cfa %rbp, 16    # this should be inserted after addq $16, %rsp
        .cfi_offset %rbp, -16    # this should be after .cfi_def_cfa %rbp, 16
        addq    $16, %rsp
        popq    %rbp
        .cfi_def_cfa %rsp, 8
        retq

Fix a wrong flag name in test.

Address David's comment.
Adjust comments, function names and flag names.

refactor GetEntryForPercentile out in https://reviews.llvm.org/D83439

https://reviews.llvm.org/D82123 to always instrument function entry BB has been committed guarded by a flag. https://reviews.llvm.org/D83024 to enable the flag by default is under review.

Thanks. LGTM. Please wait and see if David has more comments.

Disable sample-profile-merge-inlinee when sample-profile-top-down-load is not effective (Currently sample-profile-top-down-load is only effective for new pass manager).

I tested the performance with sample-profile-top-down-load and sample-profile-merge-inlinee both enabled. In different compiler versions I got different result. In one version about three weeks older, I got 0.4% improvement for one benchmark steadily in multiple runs and neutral for another. In the head llvm version, I saw neutral result for both benchmarks.

Enable -sample-profile-merge-inlinee by default together with -sample-profile-top-down-load.

In D83024#2132133, @davidxl wrote:

Here version is overloaded with different meanings: 1) to indicate format change; 2) to indicate instrumentation compiler version that is capable of producing this format. These two purposes can be contradicting to each other as the user can use option to force the old format with the new compiler.

Sounds good to me. I will redo the performance test for it.

Thanks David!

Remove the compiler part since that part will be done in https://reviews.llvm.org/D82123.

I tried it on an internal benchmark.

LGTM. Thanks.

Thanks for the patch! I guess atomic update is to reduce the cost of the entry counter for application with many threads. How much difference there is w/wo enabling -atomic-first-counter?

In D81981#2099769, @davidxl wrote:

The index format needs to be backward compatible, so there needs to be some version specific handling there (can be removed later).

In D81981#2099702, @wenlei wrote:

If how we select BB to instrument depends on a switch, we would need instrumentation build and optimizing build to have consistent switch, otherwise counters could mismatch even if CFG checksum matches? I guess that's one reason why it'd be good to avoid different ways of selecting BBs.

In D81981#2099452, @davidxl wrote:

Why is the profile size increase? I expect the number of instrumented blocks remain mostly unchanged.

The reason for the question is that if the overhead is low, I think we should make the default to be true.

In D81981#2099070, @davidxl wrote:

I think it is good to have an entry counter always, so that the profile dump is more readable. Do you have data showing the instrumentation overhead and profile size impact (clang and some large app)?

Thanks for adding the feature.

Based on my limited knowledge of new pass manager, this change looks good. Please wait another day or two before commit in case Chandler has some comment.

Thanks for catching the mistake!

LGTM.

Address MaskRay's comment.

LGTM.

Address MaskRay's comment and fix a bunch of tests.

LGTM.

In D79959#2047294, @wenlei wrote:

I guess you accidentally missed InlineCost.cpp in latest version?

Address Hongtao's comment.

Address Wenlei's comment.

In D79959#2040039, @davidxl wrote:

If this is for experimental use, why not just introducing a LLVM internal option that specify a list of function to be skipped? It should be applied to inline instances of the function specified?

In D79959#2040033, @wenlei wrote:

If we make it a function attribute, do we need to reject pre-LTO (CGSCC) inlining between function with different attribute value? If we always expect this attribute to be consistent among functions from the same module, this won't be a problem. However having it as a function attribute does offer function level flexibility (e.g. if this is exposed through __attribute(..)__), and we may want to account for it..

Address David's comment.

D79600 is a followup and the discussion about it won't affect this change, so I will go ahead and submit the change.

Although less likely, is there possiblity that someone has already been using attribute((section(".text.hot."))? Adding another trailing period will break the existing usage. We may either tolerate that case, or trigger an assertion.