[PATCH] D104060: Machine IR Profile

[Kyungwoo Lee via Phabricator via llvm-commits]

kyulee added a comment.

In D104060#2828641 <https://reviews.llvm.org/D104060#2828641>, @MaskRay wrote:

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

Thanks for the patch D104556 <https://reviews.llvm.org/D104556> that uses PC relative relocations for reference! This avoids dynamic relocation, which is the prerequisite to make a section (region) be extractable.
Unfortunately this is not sufficient because we need to find the references once they are extracted out because the address ranges (either in the original binary and the extracted binary) are not valid or can be altered.
So, we need some notion of section (or region) relative addressing which is not all available in COFF/ELF/MachO. One trick in MIP is to introduce an anchor reference to express such addressing with two PC relative relocations.
In fact, this anchor reference can be hoisted out into the header which we can share, which is not in this change yet.
To interoperate and make all different `__llvm_prof_*`  be extractable, I think we should introduce a header (weak or comdat) like MIP for each __llvm_prof_* and bookkeep distance/relocations within it across regions.
I can see it's technically doable but the cost and risk seems high since we need to restructure `__llvm_prof_*` and its dependencies. If we're meant to just introduce another section like `__llvm_mipmap` under a flag in LLVM IR infra, this is just confusing.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104060