[all-commits] [llvm/llvm-project] ab34ab: [PseudoProbe] Use callee name as callsite identfie...

[Hongtao Yu via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: ab34ab2b87a58a0bce17ed32460fc22093e1a3f2
      https://github.com/llvm/llvm-project/commit/ab34ab2b87a58a0bce17ed32460fc22093e1a3f2
  Author: Hongtao Yu <hoy at fb.com>
  Date:   2022-06-08 (Wed, 08 Jun 2022)

  Changed paths:
    M llvm/include/llvm/MC/MCPseudoProbe.h
    M llvm/lib/MC/MCPseudoProbe.cpp

  Log Message:
  -----------
  [PseudoProbe] Use callee name as callsite identfier for MCDecodedPseudoProbeInlineTree.

The callsite identifier used in pseudo probe encoding and decoding is consisted of a function name and the callsite probe id. For encoding, i.e., `MCPseudoProbeInlineTree`, the function name is callee function name. However for decoding, i.e., `MCDecodedPseudoProbeInlineTree`, the caller function name is used actually. This results in multiple callees that are inlined at the same callsite, likely via indirect call promotion, sharing the same decoded inline frame. While it is not a problem for profile generation, it confuses probe re-encoding in Bolt.

In Bolt, we decode pseudo probes first and build `MCDecodedPseudoProbeInlineTree`. The decoded tree is used for final re-encoding. Here comes the problem. Two inlinees from the same callsite share the same decoded inline frame. During re-encoding, the frame name (whatever inlinee comes first) will be used and encoded in the bolted binary. This will cause wrong inline contexts  in the profile generated on the bolted binary.

The fix is a no-op to pre-bolt profile generation. Some of the bolt tests are not yet upstreamed, thus I'm not adding a bolt test here.

Reviewed By: wenlei

Differential Revision: https://reviews.llvm.org/D126434