[llvm] [MemProf] Fix when CallStackTrie is a single chain with multi alloc type (PR #79433)

[Teresa Johnson via llvm-commits]

teresajohnson wrote:

Sorry for the slow reply, I have been mostly OOO for the past week.

> I think the reason is that the callstack's raw address is not same but the correspond function name, line offset and column are same. This happens when compiler unrolls the loop or does other similar optimization. So I think we may use Frame stack not address stack as key to identify unique `AllocSites` in `llvm-profdata`. Problem demo:

Interesting, I do agree that llvm-profdata should merge these. @snehasish is the person most familiar with the llvm-profdata code, but he is currently OOO as well. 

> 
> ```
> Stack for id 2:
>     #0 0x2aeb0d in operator new[](unsigned long) /data00/lifengxiang.1025/lfx/llvm-project/compiler-rt/lib/memprof/memprof_new_delete.cpp:52:3
>     #1 0x2afe5a in foo() /data00/lifengxiang.1025/test/memprof1/b.cpp:6:16
>     #2 0x2afdf4 in main /data00/lifengxiang.1025/test/memprof1/a.cpp:4:5
>     #3 0x7ffbdc9d609a in __libc_start_main /build/glibc-vjB4T1/glibc-2.28/csu/../csu/libc-start.c:308:16
> 
> Stack for id 3:
>     #0 0x2aeb0d in operator new[](unsigned long) /data00/lifengxiang.1025/lfx/llvm-project/compiler-rt/lib/memprof/memprof_new_delete.cpp:52:3
>     #1 0x2afe79 in foo() /data00/lifengxiang.1025/test/memprof1/b.cpp:6:16
>     #2 0x2afdf4 in main /data00/lifengxiang.1025/test/memprof1/a.cpp:4:5
>     #3 0x7ffbdc9d609a in __libc_start_main /build/glibc-vjB4T1/glibc-2.28/csu/../csu/libc-start.c:308:16
> ```



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