[llvm] [MemProf] Handle missing tail call frames (PR #75823)

[Snehasish Kumar via llvm-commits]

snehasish wrote:

> > Hi, @teresajohnson. I have one question. For example, there are two call chain:
> > ```
> > A->B(tail call)->C(tail call)->D(tail call)->G
> > A->B(tail call)->E(tail call)->F(tail call)->G
> > ```
> > 
> > 
> >     
> >       
> >     
> > 
> >       
> >     
> > 
> >     
> >   
> > It seems in `calleesMatch` only the chain(A->B->C->D->G) will be recorded while the chain(A->B->E->F->G) won't. Is this what you expected?
> 
> Yes I should have mentioned that this algorithm is greedy and therefore won't currently find all possible paths, so we would miss the second case here. I was thinking it was a simple extension to handle all paths, but there is a slight complication. I hacked up the change to see how difficult it would be and it works for a test case like this, but I need to do a bit broader testing of it.
> 
> Not sure yet whether it is worth handling this in this patch or as a follow-on. Let me do a bit more investigation on my prototyped change and circle back. 

The behaviour I prefer is that we only perform cloning for unambiguous cases (as far as we can get with dynamic profiles). I think we should enumerate all paths up and treat multiple paths as unreachable. This mimics the behaviour of the [missing frame inference logic in SampleProf](https://github.com/llvm/llvm-project/blob/7c9c807fa4337c8ae36296e99df529938aba4335/llvm/tools/llvm-profgen/MissingFrameInferrer.cpp#L131-L134). I'm wary of the downsides of false positives since we may degrade performance. Do you have any stats on unambiguous matches vs total matches?

Handling in a separate patch sounds fine to me.

https://github.com/llvm/llvm-project/pull/75823