[PATCH] D104060: Machine IR Profile

[Xinliang David Li via llvm-commits]

On Wed, Jun 16, 2021 at 7:08 PM Kyungwoo Lee via Phabricator <
reviews at reviews.llvm.org> wrote:

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

IR instrumentation supports indirect call target profiling. I suppose MIP
has a lightweight mechanism at the cost of tracking precision? Anyway, I
don't think this is not something IR instrumentation can not have.

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

Edge profiling helps size optimization as well -- we recently added
OptimizeForSize support at BB level so that cold blocks can be better size
optimized.

Another plug -- if you are interested in size optimization, the ML based
size optimization is also available in LLVM -- it beats -Oz.


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

-fcs-profile-generate is very late in the IR pipeline after inlining
transformations, so there is very little information loss when passing to
MIR.



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

Do you mean 'converting MIP' for IR passes?

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

yes.

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

It is fine to do this under an option and produce profile data with
different magic number or flavor bit -- this is well supported.


David



> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20210616/f3ca1f54/attachment.html>