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

[Teresa Johnson via llvm-commits]

teresajohnson 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?

This is a good point, and in fact much simpler and likely will be effective in the vast majority of cases: I had earlier collected stats from a large application profiled with tail call optimization enabled, and found that 98% of the profiled callees were found via only 1 level of tail call. In that case we know for sure the function of the missing frame (from the call in the IR of the profiled caller frame). What we don't know is which tail call it is if there are multiple on different calls to the same callee. For now my handling will be somewhat imperfect in this case (we might clone the wrong one), but I think this is probably not a common enough case to be too concerned with unless we see otherwise.

> 
> Handling in a separate patch sounds fine to me.

When I am back from the holiday I may just modify the patch to be conservative if there are multiple paths through tail calls in different functions.

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