This is an archive of the discontinued LLVM Phabricator instance.

Support for remapping profile data, for sample-based profiling.
ClosedPublic

Authored by rsmith on Aug 24 2018, 6:27 PM.

Diff Detail

Repository
rL LLVM

Event Timeline

rsmith created this revision.Aug 24 2018, 6:27 PM
davidxl added inline comments.Aug 27 2018, 9:07 AM
include/llvm/ProfileData/SampleProfReader.h
518 ↗(On Diff #162529)

Can add some documentation on the class.

Also why put Itanium in the class name? The user provided remapping file should be independent of any C++ ABIs.

lib/ProfileData/SampleProfReader.cpp
833 ↗(On Diff #162529)

Ideally, there should be a tool to convert the compact format file into a non-compact file. The nocompat file is then fed into the profile remapping tool which converts the profile to the remapped namespace.

davidxl added a reviewer: wmi.Aug 27 2018, 9:08 AM
wmi added a comment.Aug 27 2018, 11:13 AM

We do not support remapping indirect branch target information, but all other profile data should be remapped appropriately.

Any particular reason for that? Without support of call target, the performance could still be hurt badly after the renaming.

lib/ProfileData/SampleProfReader.cpp
833 ↗(On Diff #162529)

Most of the time, we can regenerate the non-compact profile and use the remapping tool to convert the non-compact profile directly. Currently I don't see I have the need to convert non-compact profile directly. We may leave the request there for the moment until we need it.

rsmith updated this revision to Diff 162726.Aug 27 2018, 12:35 PM

Added documentation comment.

In D51248#1214761, @wmi wrote:

We do not support remapping indirect branch target information, but all other profile data should be remapped appropriately.

Any particular reason for that? Without support of call target, the performance could still be hurt badly after the renaming.

Yes, the idea here is that the user doesn't need to specify which mappings have already happened (there is no "before" / "after", and no "remangling" step, just two name components that are to be treated as "the same"). That works well for most profile data: we can intercept queries for a call to foo(std::__1::string) and look up any names that are "similar" to that. But it doesn't work so easily for indirect call targets, where we would need to check (demangle and attempt to match) all functions within the module in order to determine what a particular indirect call target is transformed into. If it's important to be able to handle this, I think the cleanest way to do it would be for the profile data consumer to pass a list of all "known" function names into the reader to support such remapping. (Another approach would be to add a remangling step and require the equivalences to be specified as before -> after transformations, but that would add substantially more complexity and puts a maintenance burden on all future extensions to the demangler, so it wouldn't be my preference.)

I think this is something that we should incrementally add later, even if we already know for sure that we'll need it.

include/llvm/ProfileData/SampleProfReader.h
518 ↗(On Diff #162529)

(Comment added.)

Remapping is supported only for Itanium manglings for now, and that's all this class supports as a consequence. While I think it should be feasible to support remapping MS ABI manglings with largely the same interface, it seems reasonable to me to give this class the more specific name until we generalize it.

But I don't feel at all strongly about this, and I'm happy change the name if you prefer. If we drop the Itanium here, I think it'd make sense to also drop it from the ProfileRemappingReader with a view to it (eventually) hiding the difference between the mangling schemes there.

davidxl added inline comments.Aug 30 2018, 9:44 AM
unittests/ProfileData/SampleProfTest.cpp
120 ↗(On Diff #162726)

directly using raw name will break compact format testing.

wmi accepted this revision.Aug 31 2018, 12:09 PM

LGTM.

lib/ProfileData/SampleProfReader.cpp
830 ↗(On Diff #162726)

Nit: SampleProfileReaderItaniumRemapper assumes the underlying reader has already read in the profile. The override function read() here is a little misleading that people may think SampleProfileReaderItaniumRemapper can both read in the profile and do the remapping. May be just rename it as remap()?

This revision is now accepted and ready to land.Aug 31 2018, 12:09 PM
rsmith updated this revision to Diff 168905.Oct 9 2018, 4:35 PM
rsmith marked an inline comment as done.

Rebase and extend testing to cover raw binary format.

rsmith added inline comments.Oct 9 2018, 4:36 PM
unittests/ProfileData/SampleProfTest.cpp
120 ↗(On Diff #162726)

getSamplesFor converts the name to MD5 if the profile is in compact format.

@davidxl Do you have any more thoughts on this before I submit?

looks fine to me.

This revision was automatically updated to reflect the committed changes.