[PATCH] D140764: [MemProf] Fix inline propagation of memprof metadata
Teresa Johnson via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Thu Dec 29 12:39:08 PST 2022
tejohnson created this revision.
tejohnson added reviewers: snehasish, davidxl.
Herald added a subscriber: hiraditya.
Herald added a project: All.
tejohnson requested review of this revision.
Herald added a project: LLVM.
It isn't correct to always remove memprof metadata MIBs from the
original allocation call after inlining.
Let's say we have the following partial call graph:
C D
\ /
v v
B E
| /
v v
A
where A contains an allocation call. If both contexts including B have
the same allocation behavior, the context in the memprof metadata on the
allocation will be pruned, and we will have 2 MIBs with contexts:
A,B and A,E.
Previously, if we inlined A into B we propagate the matching MIBs onto
the inlined allocation call in B' (A,B in this case), and remove it from
the original out of line allocation in A. This is correct if we have a
single round of bottom up inlining.
However, in the compiler we can have multiple invocations of the inliner
pass (e.g. LTO). We may also inline non-bottom up with an alternative
inliner such as the ModuleInliner. In that case, we could end up first
inlining B into C, without having inlined A into B. The call graph then
looks like:
D
|
v
C' B E
\ | /
v v v
A
If we subsequently (perhaps on a later invocation of bottom up inlining)
inline A into B, the previous handling would propagate the memprof MIB
context A,B up into the inlined allocation in B', and remove it from the
original allocation in A. The propagation into B' is fine, however, by
removing it from A's allocation, we no longer reflect the context coming
from C'.
To fix this, simply prevent the removal of MIB from the original
allocation callsites.
Repository:
rG LLVM Github Monorepo
https://reviews.llvm.org/D140764
Files:
llvm/lib/Transforms/Utils/InlineFunction.cpp
llvm/test/Transforms/Inline/memprof_inline.ll
llvm/test/Transforms/Inline/memprof_inline2.ll
-------------- next part --------------
A non-text attachment was scrubbed...
Name: D140764.485638.patch
Type: text/x-patch
Size: 8460 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20221229/21ff0236/attachment.bin>
More information about the llvm-commits
mailing list