-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
Implement optimization fuel and re-enable struct field reordering #40377
Conversation
r? @arielb1 (rust_highfive has picked a reviewer for you, use r? to override) |
To be honest, we probably want: r? @eddyb |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, except for the (accidental) submodule changes.
8bd1709
to
de905e3
Compare
src/librustc/session/mod.rs
Outdated
@@ -504,6 +518,33 @@ impl Session { | |||
println!("Total time spent decoding DefPath tables: {}", | |||
duration_to_secs_str(self.perf_stats.decode_def_path_tables_time.get())); | |||
} | |||
|
|||
/// We want to know if we're allowed to do an optimization for crate crate. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is "crate crate" intentional?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Weirdly I'm going to go with yes, though crate foo might be a better choice for this phrasing. It's something I would write, though, with the intent that the redundant crate is a variable.
I was going to cc @rust-lang/compiler, but I think I'll also nominate it for discussion tomorrow. |
src/librustc/ty/layout.rs
Outdated
// The odd pattern here avoids a warning about the value never being read. | ||
if can_optimize { can_optimize = false; } | ||
let can_optimize = (fields.len() > 2 || StructKind::EnumVariant == kind) | ||
&& ! (repr.c || repr.packed || repr.linear || repr.simd); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This seems to be a change in behavior (and though seemingly correct, I want to make sure): before we didn't optimize for repr(c)
and repr(packed)
, now repr(linear)
and repr(simd)
are presumably added.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We didn't optimize for repr(simd)
before. There might be a case for removing it from the condition. Simd vectors (used to?) go through Layout::Vector
. I'm not as familiar with the details as I used to be: I had to leave this for a month in the middle. But I think leaving it for clarity is fine.
repr(linear)
is not a thing externally. It exists because we need to be able to remember which structs reordering was disabled for when using optimization fuel. It is so named because there has been talk of making an RFC that adds it, and at this point it would just be exposing it via the parser.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Layout::Vector
is still unchanged, so repr.simd
should never be true
here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you want me to kill it? I can, but it seems like the kind of thing where we might get rid of Layout::Vector
and get mysterious breakage and I don't think it's doing any harm.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nah it's fine like this.
Discussed in @rust-lang/compiler -- let's land this thing! It'd be nice to have some sort of tests. We talked about having a test that checks that we disabled reordering on one out of two structs (by supplying one unit of fuel). We might have to adjust the test in the future but for now it's ok. |
I hope to do the tests this evening when I get back. Should they be under |
@camlorn Maybe an |
@eddyb But this means it won't have a UI. |
@camlorn It's in AST order, i.e. |
@eddyb I can't get to this tonight, it's going to have to be the morning. It will not be some morning in a month from now, it will be tomorrow morning. |
Okay. There we go. 100% test coverage. And I don't think any of them are even fragile. |
@bors r+ |
📌 Commit 94a0375 has been approved by |
🔒 Merge conflict |
@bors retry |
🔒 Merge conflict |
94a0375
to
3fb94b7
Compare
@bors: r=eddyb |
📌 Commit 3fb94b7 has been approved by |
Wait, what happened here? |
bors is getting confused nowadays due to submodule updates and such, so it'll think there's a merge conflict when there isn't one. I rebased the branch and r+'d it. |
💔 Test failed - status-travis |
@eddyb No one is really sure how in the world the compiler passed all the tests in January at this point, but, well, it did. |
I figured out what was happening: in However, @arielb1's #39628 resulted in the shims in those cases (e.g. again, The only reason it didn't break before is because such functions are rare and require unstable Rust to write - the only semi-common example I can think of is |
⌛ Testing commit e18c59f with merge 9aacb72... |
Implement optimization fuel and re-enable struct field reordering See [this discussion](https://internals.rust-lang.org/t/rolling-out-or-unrolling-struct-field-reorderings/4485) for background. This pull request adds two new compilation options: `-Z print-fuel=crate` prints the optimization fuel used by a crate and `-Z fuel=crate=n` sets the optimization fuel for a crate. It also turns field reordering back on. There is no way to test this feature without something consuming fuel. We can roll this back if we want, but then the optimization fuel bits will be dead code. The one notable absence from this PR is a test case. I'm not sure how to do one that's worth having. The only thing I can think of to test is `-Z fuel=foo=0`. The problem with other tests is that either (1) they're so big that future optimizations will apply, thus breaking them or (2) we don't know which order the optimizations will be applied in, so we can't guess the message that will be printed. If someone has a useful proposal for a good test, I certainly want to add one.
This version enables [struct field reordering][1] which brings the size of the types for specified values of some CSS properties under the threshold such that they shouldn’t be boxed anymore, making test unit fail. Simly unboxing them moves the test failure to Stylo’s unit test, since the stable compiler used in that case does not do field re-ordering. Therefore, we manually reorder a couple fields to effectively bring this optimization to older compilers for a few specific types. [1]: rust-lang/rust#40377
This version enables [struct field reordering][1] which brings the size of the types for specified values of some CSS properties under the threshold such that they shouldn’t be boxed anymore, making test unit fail. Simply unboxing them moves the test failure to Stylo’s unit test, since the stable compiler used in that case does not do field re-ordering. Therefore, we manually reorder a couple fields to effectively bring this optimization to older compilers for a few specific types. [1]: rust-lang/rust#40377
This version enables [struct field reordering][1] which brings the size of the types for specified values of some CSS properties under the threshold such that they shouldn’t be boxed anymore, making test unit fail. Simply unboxing them moves the test failure to Stylo’s unit tests, since the stable compiler used in that case does not do field re-ordering. Therefore, we manually reorder a couple fields to effectively bring this optimization to older compilers for a few specific types. [1]: rust-lang/rust#40377
This version enables [struct field reordering][1] which brings the size of the types for specified values of some CSS properties under the threshold such that they shouldn’t be boxed anymore, making test unit fail. Simply unboxing them moves the test failure to Stylo’s unit tests, since the stable compiler used in that case does not do field re-ordering. Therefore, we manually reorder a couple fields to effectively bring this optimization to older compilers for a few specific types. [1]: rust-lang/rust#40377
This version enables [struct field reordering][1] which brings the size of the types for specified values of some CSS properties under the threshold such that they shouldn’t be boxed anymore, making unit tests fail. Simply unboxing them moves the test failure to Stylo’s unit tests, since the stable compiler used in that case does not do field re-ordering. Therefore, we manually reorder a couple fields to effectively bring this optimization to older compilers for a few specific types. [1]: rust-lang/rust#40377
Upgrade to rustc 1.18.0-nightly (5f13a3b54 2017-04-15) This version enables [struct field reordering][1] which brings the size of the types for specified values of some CSS properties under the threshold such that they shouldn’t be boxed anymore, making unit tests fail. Simply unboxing them moves the test failure to Stylo’s unit tests, since the stable compiler used in that case does not do field re-ordering. Therefore, we manually reorder a couple fields to effectively bring this optimization to older compilers for a few specific types. [1]: rust-lang/rust#40377 <!-- Reviewable:start --> --- This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/servo/16473) <!-- Reviewable:end -->
…-04-15) (from servo:rustup); r=emilio This version enables [struct field reordering][1] which brings the size of the types for specified values of some CSS properties under the threshold such that they shouldn’t be boxed anymore, making unit tests fail. Simply unboxing them moves the test failure to Stylo’s unit tests, since the stable compiler used in that case does not do field re-ordering. Therefore, we manually reorder a couple fields to effectively bring this optimization to older compilers for a few specific types. [1]: rust-lang/rust#40377 Source-Repo: https://github.com/servo/servo Source-Revision: c453e2ef89b32798dabbb23b22cfd5a72dddf6a5 --HG-- extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear extra : subtree_revision : 89b15d84b3f4b106d58ca90b3fd18f552d1a6633
…-04-15) (from servo:rustup); r=emilio This version enables [struct field reordering][1] which brings the size of the types for specified values of some CSS properties under the threshold such that they shouldn’t be boxed anymore, making unit tests fail. Simply unboxing them moves the test failure to Stylo’s unit tests, since the stable compiler used in that case does not do field re-ordering. Therefore, we manually reorder a couple fields to effectively bring this optimization to older compilers for a few specific types. [1]: rust-lang/rust#40377 Source-Repo: https://github.com/servo/servo Source-Revision: c453e2ef89b32798dabbb23b22cfd5a72dddf6a5
…-04-15) (from servo:rustup); r=emilio This version enables [struct field reordering][1] which brings the size of the types for specified values of some CSS properties under the threshold such that they shouldn’t be boxed anymore, making unit tests fail. Simply unboxing them moves the test failure to Stylo’s unit tests, since the stable compiler used in that case does not do field re-ordering. Therefore, we manually reorder a couple fields to effectively bring this optimization to older compilers for a few specific types. [1]: rust-lang/rust#40377 Source-Repo: https://github.com/servo/servo Source-Revision: c453e2ef89b32798dabbb23b22cfd5a72dddf6a5 UltraBlame original commit: 55519369af2b2a65f2a5c2275522a8b1dc014953
…-04-15) (from servo:rustup); r=emilio This version enables [struct field reordering][1] which brings the size of the types for specified values of some CSS properties under the threshold such that they shouldn’t be boxed anymore, making unit tests fail. Simply unboxing them moves the test failure to Stylo’s unit tests, since the stable compiler used in that case does not do field re-ordering. Therefore, we manually reorder a couple fields to effectively bring this optimization to older compilers for a few specific types. [1]: rust-lang/rust#40377 Source-Repo: https://github.com/servo/servo Source-Revision: c453e2ef89b32798dabbb23b22cfd5a72dddf6a5 UltraBlame original commit: 55519369af2b2a65f2a5c2275522a8b1dc014953
…-04-15) (from servo:rustup); r=emilio This version enables [struct field reordering][1] which brings the size of the types for specified values of some CSS properties under the threshold such that they shouldn’t be boxed anymore, making unit tests fail. Simply unboxing them moves the test failure to Stylo’s unit tests, since the stable compiler used in that case does not do field re-ordering. Therefore, we manually reorder a couple fields to effectively bring this optimization to older compilers for a few specific types. [1]: rust-lang/rust#40377 Source-Repo: https://github.com/servo/servo Source-Revision: c453e2ef89b32798dabbb23b22cfd5a72dddf6a5 UltraBlame original commit: 55519369af2b2a65f2a5c2275522a8b1dc014953
See this discussion for background.
This pull request adds two new compilation options:
-Z print-fuel=crate
prints the optimization fuel used by a crate and-Z fuel=crate=n
sets the optimization fuel for a crate.It also turns field reordering back on. There is no way to test this feature without something consuming fuel. We can roll this back if we want, but then the optimization fuel bits will be dead code.
The one notable absence from this PR is a test case. I'm not sure how to do one that's worth having. The only thing I can think of to test is
-Z fuel=foo=0
. The problem with other tests is that either (1) they're so big that future optimizations will apply, thus breaking them or (2) we don't know which order the optimizations will be applied in, so we can't guess the message that will be printed. If someone has a useful proposal for a good test, I certainly want to add one.