enable PGO on x86_64-apple-darwin

[csmoe]

r? @lqd

previous take #108837

[lqd]

The linking issue from the previous PR was not problematic, and easy to workaround locally. The resulting profiling data however caused errors depending on the binary tools used via cmake (between the llvm distributed tools and the osx devtools).
And then PGO wasn't able to find the data it needed when instrumenting, whereas on linux they're found immediately.

Compared to not using PGO on the same master commit, what are the benchmark results you're seeing locally with this PR ?

Until then, let's keep this as a draft, its not clear it's ready to be reviewed yet.
@rustbot author

[csmoe]

Your previous PR wasn't problematic indeed, tried to rebase it with master, but a bit annoying to resolve conflicts in yaml file, so I created this one.

I work on an Apple M1 machine, still building.

The resulting profiling data however caused errors depending on the binary tools used via cmake

could you elaborate more about this?

[jyn514]

Please run x test --stage 2 locally on this before enabling it by default. We don't test PGO in CI: #109535

[jyn514]

Actually that might not do the right thing; you need to get a PGO compiler to run the tests somehow, I don't know if x is able to do that. If not you may need to use build.rustc and x test --stage 0 in a second checkout.

[lqd]

Please run x test --stage 2 locally on this before enabling it by default

Tests, and benchmarks, yes. As I said before, I'm still working on this myself for rustc rather than LLVM, and I'm not sure similar changes would be enough: I have done this before and it wasn't enough just yet, but maybe I did it wrong; we'll see once we have some feedback about the results.

[lqd]

#110792 may add hurdles to this and #108837.

Our experimenting is fine, and good results could help in this discussion, but it seems unlikely that PGO would fit in the current runners time budget, under the exact same CI structure.

[csmoe]

The initial motivation of this PR pair with #110605 is trying to dist PGO'ed rust toolchain for a huge monorepo, if rust-ci resources is restricted, a dry-run might be enough to make sure the PGO flow work on macos.

[jyn514]

I wouldn't trust --dry-run to tell you whether it will actually work or not. I don't like the idea of having code here that's only intended for external projects and we never use in CI.

[lqd]

to make sure the PGO flow work on macos

What results did you have locally:

• do tests still pass with your PGOed compiler ?
• what is the difference in performance (on rustc-perf benchmarks or your external huge monorepo, whichever is easier to gather) with your PGOed compiler, compared to the same rustc commit but built without PGO ?

[csmoe]

I wouldn't trust --dry-run to tell you whether it will actually work or not. I don't like the idea of having code here that's only intended for external projects and we never use in CI.

To be clear, I'm not injecting unused code into rust-ci, but making the pgo flow more easier to reuse like a generic function.

Still testing locally, I'll post the benchmarks of rust-ci and the monorepo both here in the future.

[bors]

☔ The latest upstream changes (presumably #112013) made this pull request unmergeable. Please resolve the merge conflicts.

[Dylan-DPC]

@csmoe any updates on this?

[csmoe]

@Dylan-DPC sorry, I'll retry this week.

[Dylan-DPC]

cool no worries :)

[Dylan-DPC]

Closing this as inactive. Feel free to reöpen this pr or create a new pr if you get the time to work on this. Thanks