[PATCH] D104060: Machine IR Profile

[Xinliang David Li via llvm-commits]

On Wed, Jun 16, 2021 at 8:46 PM Kyungwoo Lee <kyulee at fb.com> wrote:

>
>
> 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.
>
>
>
> I understand IR instrumentation has value-profile for indirect call
> targets at call-site. I don’t think IR instrumentation covers dynamic
> dispatch call-site like msgSend whose target resolution happens at runtime.
> Instead of instrumenting each call-site, MIP tracks return address values
> at the function entry via a sort of back-tracking to reconstruct call-edges
> regardless of all type of calls – direct, indirect, or dynamic.
> MIP does this instrumentation at post-RA where assembly level coding is
> relatively straightforward. I think doing this at IR before frame-lowering
> will need extra overhead/mechanic to ensure this instrumentation happens in
> the very beginning of function.
>
>
>

Basically the callsite context (counter) is passed to the caller so it can
do the profiling. GCC does that too.

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.

Also if edge profiling is available, profiling direct calls will be a waste
as the information can be deduced.

David



> 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?
>
>
>
> Yes. MIP is not IR-attached, but rather tagged on machine address with
> which we can easily correlate debug data.
> So, it’s possible to construct a SamplePGO profile that is consumable 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/5b757657/attachment.html>