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

Implement optimization fuel and re-enable struct field reordering #40377

Merged
merged 9 commits into from Apr 12, 2017

Conversation

@camlorn
Copy link
Contributor

camlorn commented Mar 9, 2017

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.

@rust-highfive
Copy link
Collaborator

rust-highfive commented Mar 9, 2017

r? @arielb1

(rust_highfive has picked a reviewer for you, use r? to override)

@camlorn
Copy link
Contributor Author

camlorn commented Mar 9, 2017

To be honest, we probably want:

r? @eddyb

@rust-highfive rust-highfive assigned eddyb and unassigned arielb1 Mar 9, 2017
@eddyb
eddyb approved these changes Mar 9, 2017
Copy link
Member

eddyb left a comment

LGTM, except for the (accidental) submodule changes.

@camlorn camlorn force-pushed the camlorn:optimization_fuel branch from 8bd1709 to de905e3 Mar 9, 2017
@@ -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.

This comment has been minimized.

@retep998

retep998 Mar 9, 2017 Member

Is "crate crate" intentional?

This comment has been minimized.

@camlorn

camlorn Mar 9, 2017 Author Contributor

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.

@eddyb
Copy link
Member

eddyb commented Mar 9, 2017

I was going to cc @rust-lang/compiler, but I think I'll also nominate it for discussion tomorrow.

// 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);

This comment has been minimized.

@Mark-Simulacrum

Mark-Simulacrum Mar 9, 2017 Member

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.

This comment has been minimized.

@camlorn

camlorn Mar 9, 2017 Author Contributor

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.

This comment has been minimized.

@eddyb

eddyb Mar 9, 2017 Member

Layout::Vector is still unchanged, so repr.simd should never be true here.

This comment has been minimized.

@camlorn

camlorn Mar 9, 2017 Author Contributor

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.

This comment has been minimized.

@eddyb

eddyb Mar 9, 2017 Member

Nah it's fine like this.

@nikomatsakis
Copy link
Contributor

nikomatsakis commented Mar 9, 2017

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.

@camlorn
Copy link
Contributor Author

camlorn commented Mar 9, 2017

I hope to do the tests this evening when I get back. Should they be under run-pass? Going to hit the no fuel and 1 fuel cases.

@eddyb
Copy link
Member

eddyb commented Mar 9, 2017

@camlorn Maybe an ui test for the layout of the structs? i.e. like the existing ones you updated here.

@camlorn
Copy link
Contributor Author

camlorn commented Mar 9, 2017

@eddyb
that would require knowing which one is being optimized. @nikomatsakis's idea is better: get the size of 2 structs and assert that only one of them is right.

But this means it won't have a UI.

@eddyb
Copy link
Member

eddyb commented Mar 9, 2017

@camlorn It's in AST order, i.e. struct Foo; struct Bar; will need 1 for the first and 2 for both.
That's ignoring on-demand but on-demand should only kick in if you mention that type elsewhere.

@camlorn
Copy link
Contributor Author

camlorn commented Mar 10, 2017

@eddyb
I will do a UI test if that is what you really really want. But it's kind of overkill. All we have to do is ask if the size is right, because a bunch of other tests already cover the optimization itself.

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.

@camlorn
Copy link
Contributor Author

camlorn commented Mar 10, 2017

Okay. There we go. 100% test coverage. And I don't think any of them are even fragile.

@eddyb
Copy link
Member

eddyb commented Mar 10, 2017

@bors r+

@bors
Copy link
Contributor

bors commented Mar 10, 2017

📌 Commit 94a0375 has been approved by eddyb

@bors
Copy link
Contributor

bors commented Mar 13, 2017

🔒 Merge conflict

@eddyb
Copy link
Member

eddyb commented Mar 13, 2017

@bors retry

@bors
Copy link
Contributor

bors commented Mar 13, 2017

🔒 Merge conflict

@alexcrichton alexcrichton force-pushed the camlorn:optimization_fuel branch from 94a0375 to 3fb94b7 Mar 13, 2017
@alexcrichton
Copy link
Member

alexcrichton commented Mar 13, 2017

@bors: r=eddyb

@bors
Copy link
Contributor

bors commented Mar 13, 2017

📌 Commit 3fb94b7 has been approved by eddyb

@camlorn
Copy link
Contributor Author

camlorn commented Mar 13, 2017

Wait, what happened here?

@alexcrichton
Copy link
Member

alexcrichton commented Mar 13, 2017

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.

@bors
Copy link
Contributor

bors commented Apr 11, 2017

💔 Test failed - status-travis

@TimNN
Copy link
Contributor

TimNN commented Apr 11, 2017

@bors retry

@camlorn
Copy link
Contributor Author

camlorn commented Apr 11, 2017

@eddyb
Just to repeat what got said on IRC for anyone else following, we did fix stuff related to this already.

No one is really sure how in the world the compiler passed all the tests in January at this point, but, well, it did.

@eddyb
Copy link
Member

eddyb commented Apr 11, 2017

I figured out what was happening: in rustc_trans we used to have a few shims that proxied their arguments irrespective of their types - that means that extern "rust-call" fn shims (e.g. Fn trait objects) only saw the expanded tuples, and never had a value of the tuple type.

However, @arielb1's #39628 resulted in the shims in those cases (e.g. again, Fn trait object) being translated the same way as functions defined extern "rust-call" fn, which involved the incorrect code storing arguments to tuple fields, never have been fixed until today.

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 FnBox which isn't usually used with multiple arguments.

@bors
Copy link
Contributor

bors commented Apr 11, 2017

Testing commit e18c59f with merge 9aacb72...

bors added a commit that referenced this pull request Apr 11, 2017
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.
@frewsxcv
Copy link
Member

frewsxcv commented Apr 11, 2017

@bors retry

prioritizing #41231 since everything in the queue will fail without it

frewsxcv added a commit to frewsxcv/rust that referenced this pull request Apr 11, 2017
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.
bors added a commit that referenced this pull request Apr 12, 2017
Rollup of 8 pull requests

- Successful merges: #40377, #40559, #41173, #41202, #41204, #41209, #41216, #41231
- Failed merges:
@bors
Copy link
Contributor

bors commented Apr 12, 2017

Testing commit e18c59f with merge da32752...

@bors bors merged commit e18c59f into rust-lang:master Apr 12, 2017
1 of 2 checks passed
1 of 2 checks passed
homu Testing commit e18c59f with merge da32752...
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details
SimonSapin added a commit to servo/servo that referenced this pull request Apr 15, 2017
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
SimonSapin added a commit to servo/servo that referenced this pull request Apr 15, 2017
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
SimonSapin added a commit to servo/servo that referenced this pull request Apr 15, 2017
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
SimonSapin added a commit to servo/servo that referenced this pull request Apr 15, 2017
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
SimonSapin added a commit to servo/servo that referenced this pull request Apr 15, 2017
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
bors-servo added a commit to servo/servo that referenced this pull request Apr 16, 2017
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 -->
moz-v2v-gh pushed a commit to mozilla/gecko-dev that referenced this pull request Apr 16, 2017
…-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
Manishearth pushed a commit to Manishearth/gecko-dev that referenced this pull request Apr 21, 2017
…-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
@Florob Florob mentioned this pull request Jun 7, 2017
8 of 11 tasks complete
gecko-dev-updater pushed a commit to marco-c/gecko-dev-comments-removed that referenced this pull request Oct 1, 2019
…-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
gecko-dev-updater pushed a commit to marco-c/gecko-dev-wordified that referenced this pull request Oct 1, 2019
…-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
gecko-dev-updater pushed a commit to marco-c/gecko-dev-wordified-and-comments-removed that referenced this pull request Oct 1, 2019
…-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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

You can’t perform that action at this time.