[Tracking] contextual instrumented-based PGO #89287
Assignees
Labels
PGO
Profile Guided Optimizations
Comments
mtrofin
added a commit
to mtrofin/llvm-project
that referenced
this issue
Apr 18, 2024
Add the component structure for contextual instrumented PGO and the bump allocator + test. (Tracking Issue: llvm#89287)
mtrofin
added a commit
that referenced
this issue
Apr 22, 2024
Add the component structure for contextual instrumented PGO and the bump allocator + test. (Tracking Issue: #89287, RFC referenced there)
mtrofin
added a commit
to mtrofin/llvm-project
that referenced
this issue
Apr 23, 2024
…APIs APIs for contextual profiling. (Tracking Issue: llvm#89287, RFC referenced there)
mtrofin
added a commit
to mtrofin/llvm-project
that referenced
this issue
Apr 24, 2024
(Tracking Issue: llvm#89287, RFC referenced there)
mtrofin
added a commit
that referenced
this issue
Apr 25, 2024
Add the callsite intrinsic. Structurally, it is very similar to the counter intrinsics, hence the inheritance relationship. We can probably rename `InstrProfCntrInstBase` to `InstrProfIndexedBase` later - because the "counting" aspect is really left to derived types of `InstrProfCntrInstBase`, and it only concerns itself with the index aspect (which is what we care about for `callsite`, too) (Tracking Issue: #89287, RFC referenced there)
mtrofin
added a commit
to mtrofin/llvm-project
that referenced
this issue
Apr 25, 2024
This adds instrumenting callsites to PGOInstrumentation, *if* contextual profiling is requested. The latter also enables inserting counters in the entry basic block and disables value profiling (the latter is a point in time change) This change adds the skeleton of the contextual profiling lowering pass, just so we can introduce the flag controlling that and the API to check that. The actual lowering pass will be introduced in a subsequent patch. (Tracking Issue: llvm#89287, RFC referenced there)
mtrofin
added a commit
to mtrofin/llvm-project
that referenced
this issue
Apr 25, 2024
This adds instrumenting callsites to PGOInstrumentation, *if* contextual profiling is requested. The latter also enables inserting counters in the entry basic block and disables value profiling (the latter is a point in time change) This change adds the skeleton of the contextual profiling lowering pass, just so we can introduce the flag controlling that and the API to check that. The actual lowering pass will be introduced in a subsequent patch. (Tracking Issue: llvm#89287, RFC referenced there)
mtrofin
added a commit
that referenced
this issue
May 1, 2024
This adds instrumenting callsites to PGOInstrumentation, *if* contextual profiling is requested. The latter also enables inserting counters in the entry basic block and disables value profiling (the latter is a point in time change) This change adds the skeleton of the contextual profiling lowering pass, just so we can introduce the flag controlling that and the API to check that. The actual lowering pass will be introduced in a subsequent patch. (Tracking Issue: #89287, RFC referenced there)
mtrofin
added a commit
to mtrofin/llvm-project
that referenced
this issue
May 2, 2024
This adds the instrumentation lowering pass. (Tracking Issue: llvm#89287, RFC referenced there)
mtrofin
added a commit
that referenced
this issue
May 7, 2024
…APIs (#89838) APIs for contextual profiling. `ContextNode` is the call context-specific counter buffer. `ContextRoot` is associated to those functions that constitute roots into interesting call graphs, and is the object on which we hang off `Arena`s for allocating `ContextNode`s, as well as the `ContextNode` corresponding to such functions. Graphs of `ContextNode`s are accessible by one thread at a time. (Tracking Issue: #89287, more details in the RFC referenced there)
mtrofin
added a commit
that referenced
this issue
May 8, 2024
This adds the instrumentation lowering pass. (Tracking Issue: #89287, RFC referenced there)
This was referenced Aug 21, 2024
mtrofin
added a commit
that referenced
this issue
Aug 21, 2024
Eventually we'll need to flatten the profile (at the end of all IPO) and lower to "vanilla" `MD_prof`. This is the first part of that. Issue #89287
mtrofin
added a commit
that referenced
this issue
Aug 22, 2024
cjdb
pushed a commit
to cjdb/llvm-project
that referenced
this issue
Aug 23, 2024
Eventually we'll need to flatten the profile (at the end of all IPO) and lower to "vanilla" `MD_prof`. This is the first part of that. Issue llvm#89287
cjdb
pushed a commit
to cjdb/llvm-project
that referenced
this issue
Aug 23, 2024
Analogous to PR llvm#104491 Issue llvm#89287
mtrofin
added a commit
that referenced
this issue
Aug 27, 2024
An overload of `llvm::promoteCallWithIfThenElse` that updates the contextual profile. High-level, this is very simple: after creating the `if... then (direct call) else (indirect call)` structure, we instrument the new callsites and BBs (the instrumentation will help with tracking for other IPO transformations, and, ultimately, to match counter values before flattening to `MD_prof`). In more detail: - move the callsite instrumentation of the indirect call to the `else` BB, before the indirect call - create a new callsite instrumentation for the direct call - create instrumentation for both the `then` and `else` BBs - we could instrument just one (MST-style) but we're not running the binary with this instrumentation, and at most this would save some space (less counters tracked). For simplicity instrumenting both at this point - update each context belonging to the caller by updating the counters, and moving the indirect callee to the new, direct callsite ID Issue #89287
This was referenced Sep 6, 2024
mtrofin
added a commit
that referenced
this issue
Sep 6, 2024
Pass to flatten and lower the contextual profile to profile (i.e. `MD_prof`) metadata. This is expected to be used after all IPO transformations have happened. Prior to lowering, the instrumentation is maintained during IPO and the contextual profile is kept in sync (see PRs #105469, #106154). Flattening (#104539) sums up all the counters belonging to all a function's context nodes. We first propagate counter values (from the flattened profile) using the same propagation algorithm as `PGOUseFunc::populateCounters`, then map the edge values to `branch_weights`. Functions. in the module that don't have an entry in the flattened profile are deemed cold, and any `MD_prof` metadata they may have is reset. The profile summary is also reset at this point. Issue [#89287](#89287)
searlmc1
pushed a commit
to ROCm/llvm-project
that referenced
this issue
Sep 7, 2024
Eventually we'll need to flatten the profile (at the end of all IPO) and lower to "vanilla" `MD_prof`. This is the first part of that. Issue llvm#89287 Change-Id: I48726b27c9017371c4dcb292ed1ce0406edbdaa6
searlmc1
pushed a commit
to ROCm/llvm-project
that referenced
this issue
Sep 7, 2024
Analogous to PR llvm#104491 Issue llvm#89287 Change-Id: I1b17e442bb2775cb05a2abe74a78d91a5211016d
searlmc1
pushed a commit
to ROCm/llvm-project
that referenced
this issue
Sep 7, 2024
An overload of `llvm::promoteCallWithIfThenElse` that updates the contextual profile. High-level, this is very simple: after creating the `if... then (direct call) else (indirect call)` structure, we instrument the new callsites and BBs (the instrumentation will help with tracking for other IPO transformations, and, ultimately, to match counter values before flattening to `MD_prof`). In more detail: - move the callsite instrumentation of the indirect call to the `else` BB, before the indirect call - create a new callsite instrumentation for the direct call - create instrumentation for both the `then` and `else` BBs - we could instrument just one (MST-style) but we're not running the binary with this instrumentation, and at most this would save some space (less counters tracked). For simplicity instrumenting both at this point - update each context belonging to the caller by updating the counters, and moving the indirect callee to the new, direct callsite ID Issue llvm#89287 Change-Id: I6cea45269b753c9d4b660f3e8b16f176a7281e13
mtrofin
added a commit
that referenced
this issue
Sep 10, 2024
…07499) This patch enables experimenting with the contextual profile. ICP is currently disabled in this case - will reenable it subsequently. Also subsequently the inline cost model / decision making would be updated to be context-aware. Right now, this just achieves "complete use" of the profile, in that it's ingested, maintained, and sunk to a flat profile when not needed anymore. Issue [#89287](#89287)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Anchor for PRs for initial support for contextual instrumented-based PGO.
RFC: https://discourse.llvm.org/t/rfc-contextual-profile-instrumentation-for-event-driven-scenarios/78447
The text was updated successfully, but these errors were encountered: