Skip to content

[Coverage] Refactor SIL generation for profiling #13597

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Jan 3, 2018

Conversation

vedantk
Copy link
Contributor

@vedantk vedantk commented Dec 22, 2017

This patch moves the ownership of profiling state from SILGenProfiling
to SILFunction, where it always belonged. Similarly, it moves ownership
of the profile reader from SILGenModule to SILModule.

The refactor sets us up to fix a few outstanding code coverage bugs and
does away with sad hacks like ProfilerRAII. It also allows us to locally
guarantee that a profile counter increment actually corresponds to the
SILFunction at hand.

That local guarantee causes a bugfix to accidentally fall out of this
refactor: we now set up the profiling state for delayed functions
correctly. Previously, we would set up a ProfilerRAII for the delayed
function, but its counter increment would never be emitted :(. This fix
constitutes the only functional change in this patch -- the rest is NFC.

As a follow-up, I plan on removing some dead code in the profiling
logic and fixing a few naming inconsistencies. I've left that for later
to keep this patch simple.

rdar://32588741 (& 36061003)

@vedantk
Copy link
Contributor Author

vedantk commented Dec 22, 2017

@swift-ci please smoke test

@vedantk
Copy link
Contributor Author

vedantk commented Dec 22, 2017

Hey @slavapestov and @shajrawi, mind taking a look (possibly after the winter break :)?

@vedantk
Copy link
Contributor Author

vedantk commented Dec 22, 2017

@swift-ci please smoke test

@slavapestov
Copy link
Contributor

This looks good. I'm curious why you decided to put the profiler instance in SILFunction and not SILGenFunction though -- presumably after SILGen we never need to create a profiler instance again, unless you think the optimizer will need to bump these counts too?

@shajrawi
Copy link

shajrawi commented Jan 2, 2018

LGTM! the profiler instance should be in SILFunction: the optimizer might bump / change profile counts. There's initial support in the Optimizer for profile-based inlining and propagating a profile through other optimizations (which might split a BB / unroll a loop ..etc). While the current support is partial / just a proof of concept, we might want to get back to PGO at a later date. If we do get back to PGO, being able to bump these counts in the optimizer would be extremely useful.

@vedantk
Copy link
Contributor Author

vedantk commented Jan 3, 2018

Sorry for the delay, I'm just getting back online 😅.

@slavapestov, I put the profiler instance in SILFunction for the reason Joe mentioned. It seems like this is in good shape, so I'll rebase and merge today. Thanks for taking a look!

This patch moves the ownership of profiling state from SILGenProfiling
to SILFunction, where it always belonged. Similarly, it moves ownership
of the profile reader from SILGenModule to SILModule.

The refactor sets us up to fix a few outstanding code coverage bugs and
does away with sad hacks like ProfilerRAII. It also allows us to locally
guarantee that a profile counter increment actually corresponds to the
SILFunction at hand.

That local guarantee causes a bugfix to accidentally fall out of this
refactor: we now set up the profiling state for delayed functions
correctly. Previously, we would set up a ProfilerRAII for the delayed
function, but its counter increment would never be emitted :(. This fix
constitutes the only functional change in this patch -- the rest is NFC.

As a follow-up, I plan on removing some dead code in the profiling
logic and fixing a few naming inconsistencies. I've left that for later
to keep this patch simple.
@vedantk
Copy link
Contributor Author

vedantk commented Jan 3, 2018

@swift-ci please smoke test and merge

@vedantk
Copy link
Contributor Author

vedantk commented Jan 3, 2018

@swift-ci Please smoke test

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants