In D159141#4626637, @tejohnson wrote:

Should there be a test to cover the new base class? In particular the constructor isn't called and the readNextRecord with a null Callback case.

Add unit test, address comments, cleanup unused includes in test.

Address comments.

lgtm

lgtm

lgtm

It would be great to reuse the existing corpus of splitting tests for ARM. They would cover basic functionality along with interactions with different flavours of FDO. Can you create a separate patch to move the existing tests in test/CodeGen/X86/machine-function-splitter.ll to test/CodeGen/Generic/machine-function-splitter.ll? Then we can add the triple and appropriate CHECKs for x86 and ARM.

Is there a specific reason to test MFS (on ARM) with MIR instead of .ll inputs? Only ~11% of the tests in test/CodeGen/AArch64 are in MIR, the rest are bitcode files. IMO bitcode is much easier to read, maintain and we can reuse most (all?) of the existing tests we have in machine-function-splitter.ll. So my preference would be to use bitcode unless there is a fundamental reason which blocks us from testing with bitcode.

lgtm

Can you also update llvm/test/Transforms/PGOProfile/Inputs/update_memprof_inputs.sh which generates the profraw today?

Can you add some numbers on the speedup to the patch description? Also how much is profile size reduction wall time as a fraction of the entire time?

In D155110#4495040, @tejohnson wrote:

lgtm but you could also consider collapsing both BuildIds and BuildIdsSet into a single SetVector for conciseness.

lgtm, thanks for testing the various combinations of profiles passed to each option.

lgtm

lgtm, thanks for your patience with all the suggestions!

In D153904#4456647, @snehasish wrote:

In D153904#4456588, @tejohnson wrote:

LGTM but please change description per your explanation

Hmm, I amended the commit message in my branch but after landing it I don't see it in git log. Let me try to fix up.

In D153904#4456588, @tejohnson wrote:

LGTM but please change description per your explanation

In D153904#4454737, @tejohnson wrote:

The change looks fine to me but is this patch missing the referenced unit test changes?:

Also use this new overload for existing unit test usecases.

Fix capitalization in comment.

In D152834#4439489, @spupyrev wrote:

Hmm. I was using "cpu/event=0x85,umask=0x61/u" for i-TLB misses, which we got from https://download.01.org/perfmon, which has even been moved since then. Back in 2017 (when the algorithm was developed) we thought this is the "right" event to look at, but it might not be the case. Which one would you recommend to look at? I see this page has a good description.

There are a few different sets of events which count iTLB related behaviours. The misses that matter most are the ones that stall the pipeline. This is counted by FRONTEND_RETIRED.ITLB_MISS. https://github.com/intel/perfmon/blob/main/SKL/events/skylake_core.json#L5117-L5137

lgtm

I'll remove the testcase from this CL

Actually I would prefer the foo4 based test case in this patch and in the same file too (test/CodeGen/X86/machine-function-splitter.ll). Also added a comment in the other patch D152577. Thanks!

If we commit this patch before D152399 then I think we can move the machine-function-splitter-fsafdo.ll test to D152399? It would be nice to keep the patch and it's own test in the same commit.

lgtm, looks safe to me since the context objects keep a StringRef.

lgtm

LGTM, please wait a bit in case others have any concerns.

lgtm

Fix lgtm.

lgtm

lgtm

lgtm

lgtm, remaining comments are (mostly) cosmetic.

lgtm

Should we update this too https://github.com/llvm/llvm-project/blob/main/llvm/test/tools/llvm-tli-checker/ps4-tli-check.yaml#L41

lgtm

Looks good overall, still thinking if we can make assignFunctions less monolithic and easier to follow.

lgtm

lgtm

Still need to look into assignFunctions but before I do I'm wondering if this patch can be split into two with applyImport and assignFunctions in separate patches. What do you think?

lgtm

Rebase, address comment.

Thanks for the quick review!

Address comments.

Remove unused include.

Can you leave an example of the warnings in the review discussion here for posterity? Thanks!

lgtm since I think this change is safe for existing profiles. @huangjd please confirm before submitting, thanks!

lgtm

lgtm

Looks good overall, added a few comments which are mostly cosmetic.

lgtm, I assume you will reduce these test cases too?

Rebase, remove var only used in assert.

Thanks for the review!

Address comments.

PTAL, thanks!