Skip to content
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

Support caching Clang invocations with -fprofile-use and -fprofile-instr-use. #952

Merged

Conversation

michaelwoerister
Copy link
Contributor

This PR adds support for caching Clang invocations with -fprofile-use and -fprofile-instr-use, something that will be required for supporting PGOed Rust compiler builds.

The PR only implements support for Clang. I have not had time to look into how GCC works (although from a superficial glance it looks like it might be harder to find out which files to hash exactly). Adding support for Rust should be straightforward though.

I added some unit tests and verified that things work locally, but found it hard to write end-to-end tests because of Clang's PGO setup which requires the external llvm-profdata tool to generate the .profdata file. Let me know if this is something that is required.

In #941 I expressed the concern that hashing these rather big .profdata files would take a long time. In practice this does not seem to be true. In my local tests compiling LLVM with a full cache took about 50 seconds. Caching the file hashes (so that most of the hashing work could be skipped) only reduced the total build time by a couple of seconds or so.

r? @luser

Copy link
Contributor

@luser luser left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This LGTM. Just two small things I would change.

src/compiler/gcc.rs Outdated Show resolved Hide resolved
src/compiler/gcc.rs Outdated Show resolved Hide resolved
@michaelwoerister michaelwoerister force-pushed the support-clang-profile-use branch 3 times, most recently from 271b823 to 8ba25dd Compare March 2, 2021 14:25
@michaelwoerister
Copy link
Contributor Author

Thanks for the review, @luser! I think I addressed your comments.

@glandium, would you maybe be able to spare some time for merging/reviewing this PR? The new functionality is a necessary prerequisite for distributing PGOed versions of rustc.

Copy link
Collaborator

@glandium glandium left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you also rebase on top of #971 after it's merged? Thank you. (BTW, did you intend your user email not to contain a TLD?)

@@ -169,7 +176,7 @@ counted_array!(pub static ARGS: [ArgInfo<ArgData>; _] = [
flag!("-fplugin=libcc1plugin", TooHardFlag),
flag!("-fprofile-arcs", ProfileGenerate),
flag!("-fprofile-generate", ProfileGenerate),
take_arg!("-fprofile-use", OsString, Concatenated, TooHard),
take_arg!("-fprofile-use", PathBuf, Concatenated('='), ProfileUse),
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

-fprofile-use can also be used without a value associated with it. It looks like that's true of -fprofile-instr-use too, and you don't handle those cases. There's also -fno-profile-instr-use, which you might as well add support for while you're here.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

-fprofile-use can also be used without a value associated with it.

Indeed. But the documentation does not seem to state what the semantics of that are. I'll have to dig into the source code...

There's also -fno-profile-instr-use, which you might as well add support for while you're here.

I'll look into it.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It looks like -fprofile-use without argument will try to read from ./default.profdata -- and that the implementation here already handles this correctly. I'll add a unit test for that.

@@ -275,6 +283,21 @@ where
OsString::from(arg.flag_str().expect("Compilation flag expected"));
}
Some(ProfileGenerate) => profile_generate = true,
Some(ProfileUse(path)) => {
if compiler_kind != CCompilerKind::Clang {
cannot_cache!("-fprofile(-instr)-use caching only supported for Clang");
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

no need for the (-instr) part.

@@ -275,6 +283,21 @@ where
OsString::from(arg.flag_str().expect("Compilation flag expected"));
}
Some(ProfileGenerate) => profile_generate = true,
Some(ProfileUse(path)) => {
if compiler_kind != CCompilerKind::Clang {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Another way you could do this, without adding the compiler kind, is to simply add -fprofile-use to the clang list of arguments (see args::test_multi_search), in which case it would probably be more appropriate to call this ClangProfileUse rather than ProfileUse.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, you can "override" arguments that way? That does sound like the better approach for this case.

@@ -587,7 +587,7 @@ pub fn parse_arguments(
let mut args = match arg.get_data() {
Some(SplitDwarf) | Some(TestCoverage) | Some(Coverage) | Some(DoCompilation)
| Some(Language(_)) | Some(Output(_)) | Some(TooHardFlag) | Some(XClang(_))
| Some(TooHard(_)) => cannot_cache!(arg
| Some(TooHard(_)) | Some(ProfileUse(_)) => cannot_cache!(arg
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it shouldn't be too hard to add support for clang-cl here.

@glandium glandium added this to the 0.2.16 milestone Mar 10, 2021
@michaelwoerister
Copy link
Contributor Author

Thanks for the review, @glandium!

Can you also rebase on top of #971 after it's merged? Thank you.

Will do.

(BTW, did you intend your user email not to contain a TLD?)

That was a halfhearted (and probably ineffective) attempt to keep my email address somewhat protected from spammers. It set up git like that years ago and it seems to have stuck :/

@michaelwoerister
Copy link
Contributor Author

OK, I think the version I just pushed addresses your comments, @glandium. And it does look cleaner than the previous version :)

Note: I added "support" for the -fno-profile-* flags by explicitly marking them as TooHardFlag. I can look into making them actually cacheable but I'll only do so if you think it's worth the trouble.

I was a bit surprised to find that GCC::parse_arguments() seems to treat unknown arguments as always cacheable. Is that on purpose? It seems like a somewhat dangerous default.

@michaelwoerister
Copy link
Contributor Author

@glandium, do you have an estimate on when this can be merged? Is there anything I can do to help?

@dancing-leaves
Copy link

dancing-leaves commented May 7, 2021

Hi, would love to see these changes upstreamed, tracking this PR for a while. Thanks for the work, and lets rebase and merge it already. 🙂

From what i see currently it's about this:

Can you also rebase on top of #971 after it's merged? Thank you. (BTW, did you intend your user email not to contain a TLD?)

#952 (review) (@michaelwoerister has done that)

@FilipAndersson245
Copy link

@glandium Any idea of when/if this pull request can be merged?

@mitchhentges
Copy link
Contributor

Hey @michaelwoerister, thanks for the PR, and sorry for the review delay here 😅
Would you mind rebasing this off of main and re-pushing it? I'll gladly kick off the review and landing process if you're able to update this :)

@michaelwoerister
Copy link
Contributor Author

I rebased the PR and tests are passing locally for me.

@codecov-commenter
Copy link

codecov-commenter commented Feb 18, 2022

Codecov Report

Merging #952 (dc28e0e) into main (573c9ba) will increase coverage by 0.00%.
The diff coverage is 90.56%.

Impacted file tree graph

@@           Coverage Diff           @@
##             main     #952   +/-   ##
=======================================
  Coverage   57.81%   57.82%           
=======================================
  Files          47       47           
  Lines       12055    12107   +52     
  Branches     2178     2184    +6     
=======================================
+ Hits         6970     7001   +31     
  Misses       3727     3727           
- Partials     1358     1379   +21     
Impacted Files Coverage Δ
src/compiler/clang.rs 81.60% <87.80%> (+1.90%) ⬆️
src/compiler/gcc.rs 77.12% <100.00%> (-1.88%) ⬇️
src/compiler/msvc.rs 65.46% <100.00%> (+0.57%) ⬆️
src/lru_disk_cache/lru_cache.rs 99.23% <0.00%> (-0.39%) ⬇️
src/compiler/args.rs 76.44% <0.00%> (-0.36%) ⬇️
src/compiler/compiler.rs 71.90% <0.00%> (-0.24%) ⬇️
src/compiler/rust.rs 57.70% <0.00%> (+0.14%) ⬆️
src/util.rs 58.84% <0.00%> (+0.88%) ⬆️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 573c9ba...dc28e0e. Read the comment docs.

Copy link
Contributor

@mitchhentges mitchhentges left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks Michael, and sorry about the review delay.
Let's get this landed 😎

@mitchhentges mitchhentges merged commit e8c9ca0 into mozilla:main Feb 18, 2022
@michaelwoerister
Copy link
Contributor Author

Well, that was quick :) Thanks for the review!

bors added a commit to rust-lang-ci/rust that referenced this pull request Nov 15, 2024
bump sccache for linux x86_64 to allow caching while PGO'd

This bumps sccache for linux-only jobs to allow sccache work with PGO mozilla/sccache#952

This is improvement: 2h05m -> 1h44m (from 1 run) for `dist-x86_64-linux` rust-lang#133033 (comment)

Why still use old release? Commit with improvement was old, so i used some release around. In future, more recent versions can be tested to see if there any improvements, while this one already gives one.

aarch64 update shouldn't change much, as there no PGO used.

For other OSes i will create separate PRs later.

r? infra
bors added a commit to rust-lang-ci/rust that referenced this pull request Nov 16, 2024
bump sccache for linux x86_64 to allow caching while PGO'd

This bumps sccache for linux-only jobs to allow sccache work with PGO mozilla/sccache#952

This is improvement: 2h05m -> 1h44m (from 1 run) for `dist-x86_64-linux` rust-lang#133033 (comment)

Why still use old release? Commit with improvement was old, so i used some release around. In future, more recent versions can be tested to see if there any improvements, while this one already gives one.

aarch64 update shouldn't change much, as there no PGO used.

For other OSes i will create separate PRs later.

r? infra
aarongable pushed a commit to chromium/chromium that referenced this pull request Nov 18, 2024
sccache supports `-fprofile-use` since
mozilla/sccache#952, released as part of
sccache v0.3.0, which is available in Ubuntu since 23.04 release.

Bug: 40188007
Change-Id: I5bca8350113ee1940096cd53be543abf4eaf03f7
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6013745
Reviewed-by: Nico Weber <thakis@chromium.org>
Commit-Queue: Henrique Ferreiro <hferreiro@igalia.com>
Cr-Commit-Position: refs/heads/main@{#1384244}
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants