Uh oh!
There was an error while loading. Please reload this page.
MIR-only rlibs - #119017
Conversation
saethlin
commented
Dec 16, 2023
@bors try @rust-timer queue |
This comment has been minimized.
This comment has been minimized.
bors
commented
Dec 16, 2023
[perf experiment] (crudely) implement MIR-only rlibs I realized that `-Zcross-crate-inline-threshold=always` is now basically MIR-only rlibs. So if nothing else, this is an easy way to study the perf implications of such a design. Pondering this because it would be neat to codegen MIR for the standard library differently based on build flags passed by an end user. r? `@ghost`
This comment has been minimized.
This comment has been minimized.
bors
commented
Dec 16, 2023
☀️ Try build successful - checks-actions |
This comment has been minimized.
This comment has been minimized.
rust-timer
commented
Dec 16, 2023
Finished benchmarking commit (f4568e9): comparison URL. Overall result: ❌✅ regressions and improvements - ACTION NEEDEDBenchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. While you can manually mark this PR as fit for rollup, we strongly recommend not doing so since this PR may lead to changes in compiler perf. Next Steps: If you can justify the regressions found in this try perf run, please indicate this with @bors rollup=never Instruction countThis is a highly reliable metric that was used to determine the overall result at the top of this comment.
Max RSS (memory usage)ResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
CyclesResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
Binary sizeResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
Bootstrap: 672.461s -> 1381.575s (105.45%) |
741a7a7 to
9fc5b9fComparerustbot
commented
Jan 10, 2024
Failed to set assignee to
|
bors
commented
Jan 11, 2024
☔ The latest upstream changes (presumably #119843) made this pull request unmergeable. Please resolve the merge conflicts. |
oli-obk
commented
Feb 13, 2024
The MCP has been accepted |
saethlin
commented
Feb 13, 2024
👍 This PR is still not really mergeable because it breaks proc macros. I think because I'm monomorphizing the allocator shims wrong. |
This comment has been minimized.
This comment has been minimized.
bors
commented
Mar 12, 2024
☔ The latest upstream changes (presumably #121644) made this pull request unmergeable. Please resolve the merge conflicts. |
This comment has been minimized.
This comment has been minimized.
bors
commented
Mar 19, 2024
☔ The latest upstream changes (presumably #122037) made this pull request unmergeable. Please resolve the merge conflicts. |
This comment has been minimized.
This comment has been minimized.
bors
commented
Apr 30, 2024
☔ The latest upstream changes (presumably #124558) made this pull request unmergeable. Please resolve the merge conflicts. |
joshtriplett
commented
Oct 17, 2024
How feasible would it be to opt into a MIR-only rlib for a particular dependency? That might sidestep some of the difficulties associated with using it everywhere, while allowing large crates with very few items used to opt into it to reduce how much gets compiled. |
saethlin
commented
Oct 17, 2024
If you want to try using this to cut down build times, you can investigate whether it would help by setting But thanks for pinging this PR! I'll try to rebase it up soon just to keep it alive. |
joshtriplett
commented
Oct 17, 2024
I tested this on one of my projects: Baseline:
With the three biggest crates in the dependency tree (which I use a tiny fraction of the items of) using
|
Note that CI may pass, because in line with:
I removed the line that was making the compiler bootstrap with |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
Update (same project, flags applied to the same set of 3 large crates with most items unused):
|
bors
commented
Nov 10, 2024
☔ The latest upstream changes (presumably #132173) made this pull request unmergeable. Please resolve the merge conflicts. |
ae0521d to
2749d74Compare
This comment has been minimized.
This comment has been minimized.
bors
commented
Nov 12, 2024
☔ The latest upstream changes (presumably #132843) made this pull request unmergeable. Please resolve the merge conflicts. |
2749d74 to
e358d75Compare
This comment has been minimized.
This comment has been minimized.
rust-log-analyzer
commented
Dec 8, 2024
The job Click to see the possible cause of the failure (guessed by this bot) |
bors
commented
Jan 17, 2025
☔ The latest upstream changes (presumably #135592) made this pull request unmergeable. Please resolve the merge conflicts. |
saethlin
commented
Jan 17, 2025
(I've also put this text in the PR description) I'm going to stop maintaining this branch, because I think this has basically zero chance of landing and minimal utility even if it did. If you want "delayed codegen" we already have So: If you want nearly MIR-only rlibs, just use |
Final status update:
I'm going to stop maintaining this branch, because I think this has basically zero chance of landing and minimal utility even if it did. If you want "delayed codegen" we already have
-Zcross-crate-inline-threshold=alwaysand that functionality is trivial to maintain. What this branch would bring is also delaying codegen for statics, which is not very interesting in terms of improving compile time. What it could theoretically do (and I think the hope for MIR-only rlibs was always) is make a MIR-only rlib an intermediate artifact that can be lowered with various codegen options. In practice I think the utility of that is quite dubious, since after just macro expansion the IR is already quite target-specific. This can be made to work pretty well in some scenarios, but it will always be a second-class approach and comes with a substantial amount of complexity in the compiler, and would probably have a very long trail of bugs both in the compiler and in third-party crates if MIR-only rlibs were ever used seriously (people often accidentally depend on the addresses of things being stable, which they are only if they are monomorphized a certain way).So: If you want nearly MIR-only rlibs, just use
-Zcross-crate-inline-threshold=always.Status update: The strategy I implemented in this PR is to make builds of non-rlib crates monomorphize everything they need. I was quite thorough about this and had to add a handful of hacks to make it happen.
But I now believe that was a mistake, because of how it breaks proc-macro crates. I think those crates can only work if they are able to cooperate with the compiler correctly to share types across the proc-macro bridge. Currently this is achieved by linking both against the libstd dylib, which contains monomorphizations of the allocator shims and probably a handful of other things. So in order to make this work, I at least need to figure out how to make the compiler expose all the monomorphizations of the standard library, and make the proc-macro crates link against those instead of monomorphizing their own.
Originally I was just trying to imitate MIR-only rlibs with
-Zcross-crate-inline-threshold=yes, but I think I have enough skill to actually implement the behavior. We shall see.At time of writing, set
RUSTFLAGS=-Zmir-only-libsand if each session that Cargo kicks off only compiles an rlib or an executable, every rlib should contain only MIR and the build should work. Any other configuration probably explodes unceremoniously.