[PATCH] D104060: Machine IR Profile

[David Li via Phabricator via llvm-commits]

davidxl added a comment.

In D104060#2827554 <https://reviews.llvm.org/D104060#2827554>, @ellis wrote:

> @davidxl
>
>> davidxl: For the dynamic dispatching profiling, does it handle any number of indirect targets or only supports topN?
>
> Our edge profiling patch (not included) was also designed with code size and runtime in mind. We allocate a buffer and sample return addresses, possibly overwriting old values when the buffer is full.  Data for common callsites will overwrite data for rare callsites, so I guess it's more like top N, but the size of the buffer can be as large as needed.

Neat -- so the value profile (target histogram) of a given callsite is 'distributed' into the callees -- aka each callee function allocating a fixed size buffer to track all incoming edge frequencies?  For some small utility functions, they usually have thousands of callsites (incoming edges), thus this approach may significantly reduce the profile precision for them?   The simple LRU eviction policy may be bad for some patterns like ping-pong effect.

>> davidxl: Basically the callsite context (counter) is passed to the caller so it can do the profiling. GCC does that too.
>
> Our method does not need to touch the callsite code to work. In fact, most of the implementation is done in D104089 <https://reviews.llvm.org/D104089> so we mostly only change the runtime code.

Will take a look.

>> davidxl: For IRPGO, we plan to add dynamic type profiling at some point. Once that is ready, the problem of message passing style call profiling will be handled.
>> davidxl: Also if edge profiling is available, profiling direct calls will be a waste as the information can be deduced.




Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D104060/new/

https://reviews.llvm.org/D104060