[PATCH] D104060: Machine IR Profile

[Kyungwoo Lee via Phabricator via llvm-commits]

kyulee added a comment.

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

> I think people's main question is what distinguishing features make MachineFunction instrumentation appealing.
>
>> MIP Edge Profile, Optimization
>
> The two are very inconvenient at the MachineFunction/MachineBasicBlock level...
> I don't know how you can make edge profiling work for BB transitions...

MIP does not (cannot) collect BB edge data but MachineBlock coverage as needed (optional).
But, MIP can collect call-edge data for all call-sites including dynamic dispatch calls that are not covered by LLVM IR instrumentation.
As commented earlier, MIP is initially designed for mobile applications where majority calls are dynamic. In this world, size or minimum size optimizations are typically enabled.
So, traditional speed optimizations like inlining or vectorization from BB edge profiles were not a great concern.
Instead, the MIP data were mainly used for ordering, separation, or outlining to minimize CPU penalties while saving as much size as possible.

We understand if we want an IR level profile (e.g. BB edge profiles) for IR level optimizations, it would be tricky because MIP instrument Machine IRs.
However, internally we've already experimented a SamplePGO like conversion to generate LLVM IR profile converted from MIP using symbolication.
Certainly this will lose precision, but it's generally good enough in this domain because the majority of speed optimizations will be blocked anyhow under minimum size-opt.

Nonetheless, I think it's also worth revisiting MIP-like implementation at IR level to support full IR profiles including BB edge profile by reusing as much LLVM IR instrumentation code as possible.
I do still think refactoring the profile format of the existing LLVM IR instrumentation for the integration of MIP seems too disruptive while breaking the existing infra or usage.
Instead, I'd like to keep the mipmap (metadata) layout in MC to make them extractable, and this means we may retain pseudo ops all the way down to MC from IR.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104060