Implement optimization fuel and re-enable struct field reordering

[camlorn]

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]

r? @arielb1

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

[camlorn]

To be honest, we probably want:

r? @eddyb

[eddyb]

LGTM, except for the (accidental) submodule changes.

[eddyb]

LGTM, except for the (accidental) submodule changes.

[retep998]

Is "crate crate" intentional?

[camlorn]

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]

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

[Mark-Simulacrum]

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.

[camlorn]

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.

[eddyb]

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

[camlorn]

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.

[eddyb]

Nah it's fine like this.

[nikomatsakis]

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]

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]

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

[camlorn]

@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]

@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]

@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]

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

[eddyb]

@bors r+

[bors]

📌 Commit 94a0375 has been approved by eddyb

[bors]

🔒 Merge conflict

[eddyb]

@bors retry

[bors]

🔒 Merge conflict

[alexcrichton]

@bors: r=eddyb

[bors]

📌 Commit 3fb94b7 has been approved by eddyb

[camlorn]

Wait, what happened here?

[alexcrichton]

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.

[camlorn]

@nagisa
Thanks.

Closure arguments. Figures. This was the weird bug last time.

Hoping this merges.

[eddyb]

@camlorn I'm really sorry I forgot about it, I thought it got fixed and never checked.

[bors]

💔 Test failed - status-travis

[TimNN]

@bors retry

• #40417

[camlorn]

@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]

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]

⌛️ Testing commit e18c59f with merge 9aacb72...

[frewsxcv]

@bors retry

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

[bors]

⌛️ Testing commit e18c59f with merge da32752...