[PATCH] D104060: Machine IR Profile

Fangrui Song via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Fri Jun 18 20:16:08 PDT 2021


MaskRay added a comment.

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

> I probably sound like a broken record, but we've spent a lot of time making sure the map section can be extracted correctly and that the raw section has no excess info. This is a major feature of MIP, the profile data and the function info are separated so that only the necessary data remains in the binary. The question is whether we should extend an existing pgi to support this feature or if MIP deserves to be its own framework. I do see the value in extending one of the many existing pgi to reduce duplicate work. My thoughts are that it would be too invasive to do everything we need; add one or two new sections, create a new `.profraw` and `.profmap` format, add a few flags, and extend the tools. By keeping MIP separate, we can make design decisions that align with our code size goal that may not be so easy to do in existing frameworks.

The existing `__llvm_prf_cnts`/`__llvm_prf_data` can be exacted easily as well... What functionality do you find missing?

It requires a lot of efforts to make linker garbage collection work. How does MIP work better? I don't find comdat specific code or Mach-O S_ATTR_LIVE_SUPPORT.

I have a patch to make use label differences (PC-relative relocations on ELF) for `CountersPtr`: D104556 <https://reviews.llvm.org/D104556>. The tricky part is to make COFF work because COFF has some limitation.

Do you have measurement of metadata section size, dynamic relocation size, symbol table entry size for the `__llvm_prf_*` format and MIP?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104060



More information about the llvm-commits mailing list