We had better have a test for it. It is not a strict NFC and we best verify it works as we expect -- like if we miss any place which still uses StringRef refering to string in file data buffer, we may have dangling pointer after we free the buffer.

LGTM.

In D62540#1520129, @davidxl wrote:

Why is symbol remapping an issue? old MD5 --> input symbol name -> output symbol name --> mapped MD5sum ?

In D62540#1520087, @davidxl wrote:

what is the main blocker for the longer term solution?

Longer term, the plan is to put a white list of the symbols into the profile data so that the compiler can decide if a function is newly created or simply cold.

Wei, if that is in place, is there a need for this patch?

LGTM. Thanks for fixing that.

Run internal FDO testing and the speedup is within expected range.

In D60903#1472769, @davidxl wrote:

Looked at the Instruction::updateProfWeight() --- the part that update branch_weights seems bogus -- there is need need to scale branch weight at all.

VP data needs to be scaled of course, but if 'S' or 'T' is zero, just zero them out.

Seems we did that all the time even before https://reviews.llvm.org/rL352001 (Since rL352001, we did the update even in sample profile loader pass, when we found cold inline instance was not inlined by sample profile loader). Here is the code snippet before the refactoring involved in rL352001.

In D60903#1472744, @davidxl wrote:

It is possible to for an entry with zero count -- as for instance in instrumentation PGO. Should it be fixed in place where the div by zero happens?

No major improvement or regression was found in our test.

Did the test. No major improvement or regression was found. LGTM.

In D60086#1452234, @twoh wrote:

@wmi Thank you for the concrete example! I think what we need for your example is context-sensitive profiling and function specialization, not inlining. Admittedly we don't have an infrastructure in LLVM to support context-sensitive profiling for non-inlined case and we don't perform context sensitive function specialization...

Again, my bigger concern is with using PSI->isHotCount to check the function hotness. If we want to stay with the function total count based heuristic, wouldn't it make more sense if we have something like ProfileSummaryInfo::isFunctionHotInCallGraph, which actually checks the hotness of the function itself, and use it?

I can understand the value of context-sensitive profile information, but wouldn't it be only valuable if the callsite is actually worth inlining?

In D60086#1450766, @twoh wrote:

@wmi Thanks for the reply! I can totally understand that entry count is not as precise as total count, but still don't think current implementation is the right way to address the issue. As I mentioned in the summary it compares two different things (instruction level counter vs function level counter), opens up a possibility for optimizing against wrong function (e.g. long and cold function), and makes it hard to find the root cause of the performance issue.

If we can't have a precise entry count, the right way to address the issue would be not using PSI based heuristic but using a heuristic that actually considers a total count of the function.

That is a reasonable change to me. Thanks. However it probably needs some careful performance evaluation since some tuning may be needed for that change. I will do that in our benchmarks. How does this change on performance look like on your side?

That is a good improvement. Thanks! I will evaluate how much impact it will have in our benchmarks.

Theorectically, as you said checking entry sample count rather than the total sample count makes more sense. However, the entry sample count of callsite is not as precise as function sample entry count, which is got from lbr directly. For callsite, it can get very wrong entry sample count because of missing debug information after optimization. That is why we chose total sample count instead of entry sample count when evaluating the hotness of callsite.

Thanks! The change makes a lot sense to me.

LGTM.

Thanks for the detailed answer for how to make the choices!

Thanks for working on the patch which will fix several build failures found internally! I believe the patch is already after a lot of balancing, and here are just some questions out of curiousity.

LGTM. Thanks for working on it!

In D58832#1423171, @thanm wrote:

In D58832#1422205, @wmi wrote:

We need function attribute only when we want to use different strategies for different functions. Do we need the function granularity control over the suffix elision policy?

We want to be able to eventually support ThinLTO in which you have a mix of C and Go functions (it is fairly common for Go programs to call out into C code). Without such a change we'd have to pick one policy or another and hope that it works for code generated by every front end.

Thanks for the fast response!

We need function attribute only when we want to use different strategies for different functions. Do we need the function granularity control over the suffix elision policy?

LGTM

Thanks for the review!

Add a TODO comment.

Address Chandler's comment.

Address Easwaran and Chandler's comments.

Address Easwaran and Chandler's comments.

In D58399#1402844, @eraman wrote:

One option is to call DiagnosticHandler::isMissedOptRemarkEnabled in Inliner and pass the result (bool) when creating the CallAnalyzer object. This can be ORed with whether the missed opt remark is enabled for inline-cost.

LGTM.

LGTM. There is such place in SampleProfileLoader pass. I will do the same for it.

LGTM.

Sorry it takes me some time to test the change on our major benchmarks. The results are neutral.

Address Teresa's comments.

LGTM.

LGTM.

Seems the compile time saving is got mainly because there are multiple instructions sharing the same debug location, is my understanding correct?

Seems incorrect. findFunctionSamples may be called for the same instruction multiple times due to multiple iterations of hot functions inlining or profile propagation.

LGTM.

Could you have a testcase for it?

Seems the compile time saving is got mainly because there are multiple instructions sharing the same debug location, is my understanding correct?

Address Teresa's comments.

Yes, the support is also helpful for old pass manager. Add some code to make it easier to enable sampleprofileloader pass in the pipeline of old pass manager through opt, mainly for testing purpose.

friendly ping. Please take another look.

Address Quentin's comment.

A minor update to the comment.

LGTM from my limited knowledge on discriminator. I added dblaikie to help on the review.