[PATCH] D104060: Machine IR Profile

Fri Jun 18 09:40:23 PDT 2021

MaskRay added a comment.

Some email conversations are not on Phabricator. I record a copy here so that people who are not subscribed can have a full view

> davidxl: I believe you mean -fprofile-generate or -fcs-profile-generate. -fprofile-instr-generate is based on front end AST and eventually will be hidden under -fcoverage-test for source coveraging purpose only.
> davidxl: As you can see we are currently making an effort to unify/simplify the PGO implementation. Having yet another instrumentation mechanism is doing the opposite.
>
>> As shown above, a lot of work was done to make sure the metadata can be extracted correctly.
>> Existing pgi has structured raw data that would need to be moved to the extractable metadata section.
>> Our MIP tool has a `llvm-mipdata create` command which converts the map section to an “empty” profile that can later be merged with raw profiles. Existing pgi tools do not have this extra step.
>
> davidxl: As I said, size improvement efforts (under options) are welcome for the existing IRPGO.  Another benefit is that we can have consolidated effort on improving related toolings.
>
>> MIP Edge Profile
>
> davidxl: Adding this duplicate functionality (edge profiling) makes it even less compelling to do it MIR level.
> davidxl: For the dynamic dispatching profiling, does it handle any number of indirect targets or only supports topN?
>
>> Optimization
>
> davidxl: See above, adding any missing features in the existing framework is a more prefered approach. I am yet to see convincing arguments that spinning off a new instrumentation framework is the way to go.

---

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

>> kyulee: MIP does not (cannot) collect BB edge data but MachineBlock coverage as needed (optional).
>> kyulee: But, MIP can collect call-edge data for all call-sites including dynamic dispatch calls that are not covered by LLVM IR instrumentation.

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

>> kyulee: 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.
>> kyulee: So, traditional speed optimizations like inlining or vectorization from BB edge profiles were not a great concern.
>> kyulee: Instead, the MIP data were mainly used for ordering, separation, or outlining to minimize CPU penalties while saving as much size as possible.

> davidxl: Edge profiling helps size optimization as well -- we recently added OptimizeForSize support at BB level so that cold blocks can be better size optimized. 
> davidxl:
> davidxl: Another plug -- if you are interested in size optimization, the ML based size optimization is also available in LLVM -- it beats -Oz.

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

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

>> kyulee: However, internally we've already experimented a SamplePGO like conversion to generate LLVM IR profile converted from MIP using symbolication.
>> kyulee: 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.

> davidxl: Do you mean 'converting MIP' for IR passes?

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

> davidxl: yes.

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

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

---

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

>>> davidxl: Do you mean 'converting MIP' for IR passes?

>> kyulee: Yes. MIP is not IR-attached, but rather tagged on machine address with which we can easily correlate debug data.
>> kyulee: So, it’s possible to construct a SamplePGO profile that is consumable for IR passes.

> davidxl: Basically the callsite context (counter) is passed to the caller so it can do the profiling. GCC does that too.
> davidxl: 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.
> davidxl: Also if edge profiling is available, profiling direct calls will be a waste as the information can be deduced.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104060