Thanks for working on it.

I see. You already take the adjustment in insertCFIInstrs into consideration and assume the CFIs in the layout order will match CFIs in control flow in the end. In this way, .cfi_remember_state at the beginning of current BB is always assumed to remember the outgoing CFI information of its predecessor BB.

I suspect there is some problem caused by interaction of .cfi_remember_state/.cfi_restore_state and CFIInstrInserter pass.

In D32201#1620644, @wuzish wrote:

Should this good patch be rebased and continued to move on? @wmi
it'd be better to move on this work because D27366 is abandoned and D34608 is not updated for a long time, and those 3 patches are all trying to fix same issue and not landed successfully.
It would be great If it can land.

LGTM.

Thanks for the change.

Thanks for working on the issue.

Nirav, thanks for all the suggestions and quick responses!

Address Nirav's comment.

Address Nirav's comment.

Thanks for the suggestions. I will update patch immediately. Please see if it matches what is in your mind.

Address Nirav's comment.

Thanks Nirav. I update the patch. Please take a look.

In D65174#1606368, @niravd wrote:

It may not be easy for us to prune the searching space without missing some merging opportunity. I feel it is easier to achieve that goal by controlling how many times a {RootNode, StoreNode} pair appear in candidate set repeatedly. With the patch, no bit change in the binaries were found for clang and some large application. So the current patch is a safe change.

True. But my concern is that as we prune the search space, we will introduce burrs in the which will be extremely hard to find and notice. I agree that its' not worth it to solve it the ideal way, but if a quick to write but safe pruning of the search space happens to work we should go with that. If not, it's likely it'll be too hard to resolve better than a heuristics. The scheme here is fine modulo the following concerns:

1. If it's really an issue with the candidate dependence check, we should move the RootStoreCountMap update be modified in the dependency search, not the candidate check. This shouldn't dramatically change the run time.
2. The RootNode is effectively a function of the candidate store. We really should only have a single RootNode so it'd be better as a map from SDNode* to (SDNode*, int).

In D65174#1605103, @niravd wrote:

Ah. That's a tricky one. It sounds like this isn't a case of the candidate stores not being mergable, but rather us giving up before we completely verify that.

I don't suppose the values in the indirect value operands to the candidate stores have a relatively short dependence on a node not too far from the RootNode. Right now, we only prune at the root node (and components through the TokenFactors). but we could also just mark further predecessors of the RootNode as not needing to be searched.

In D65174#1604984, @fhahn wrote:

Recently we run into a case with compile time problem (27 mins in O3 but a few seconds in O0). In that case, we have a huge block containing many stores. Each time a store is visited, dagcombiner will find a candidate set all chained by the same root node for the store, then try to merge the nodes in the candidate set into a wider store. This is a quadratic algorithm, because for the same candidate set, everytime a store inside of the set is visited, the same set will be considered for merging.

Could you share the test case? I looked into a similar issue and came up with some sort of caching for the lookup. I never shared the patch, because we addressed the issue with a limit. But it might be helpful for your case.

In D65174#1604955, @niravd wrote:

I check and the reason the candidates cannot be merged isn't because of the legal size. It is that checkMergeStoreCandidatesForDependencies always returns false so https://reviews.llvm.org/D60133 doesn't help.

Ah! Interesting. I've only seen that dependence triggered from inlined memcpy.

What's the shape of the DAG here? There must be some non-standard data dependence between stores, which is not being checked. Maybe we can change the candidate search to avoid such candidates.

Thanks for pointing me to D60133.

Address Eli's comment.

Address Eli's comment.

In D65310#1601929, @efriedma wrote:

Is there any reason to expect that unreachable loops have exactly one block?

LGTM. Thanks!

Thanks for the patch.

From my last reply "I assumed the input files are small since we want to have small testcase. If the input files are small, the buffer won't be allocated through mmap but through new (From getOpenFileImpl in lib/Support/MemoryBuffer.cpp)".

This is not ready for review yet. I just upload the patch for some people's reference and discussion.

In D63671#1565126, @wmi wrote:

In D63671#1564933, @paulsemel wrote:

In D63671#1563092, @wmi wrote:

In D63671#1556584, @paulsemel wrote:

Add one test case.

Thanks. If we remove the code to replace string reference from file data buffer to FunctionNames set for call targets, will the test fail?

No, because this change is kind of a NFC, which implies that I want to keep the same behaviors as previously.
To actually have a test that fails if we remove this code, we would need to have a super heavy and time consuming test, which is, imo, not what we want for a test.

Do we really need to have a tests that fails if we remove this code ?

Is it possible to add an option to flush the file data buffer with 0 after the file is released? The option is only enabled for testing. With the option on, even with small test we can catch some difference in merge result if the patch is incorrect.

In D63671#1564933, @paulsemel wrote:

In D63671#1563092, @wmi wrote:

In D63671#1556584, @paulsemel wrote:

Add one test case.

Thanks. If we remove the code to replace string reference from file data buffer to FunctionNames set for call targets, will the test fail?

No, because this change is kind of a NFC, which implies that I want to keep the same behaviors as previously.
To actually have a test that fails if we remove this code, we would need to have a super heavy and time consuming test, which is, imo, not what we want for a test.

Do we really need to have a tests that fails if we remove this code ?

In D63671#1556584, @paulsemel wrote:

Add one test case.

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.