[MIR] Deaggregate structs to enable further optimizations

[scottcarr]

Currently, we generate MIR like:

tmp0 = ...;
tmp1 = ...;
tmp3 = Foo { a: ..., b: ... };

This PR implements "deaggregation," i.e.:

tmp3.0 = ...
tmp3.1 = ...

Currently, the code only deaggregates structs, not enums. My understanding is that we do not have MIR to set the discriminant of an enum.

[rust-highfive]

r? @nrc

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

[scottcarr]

r? @nikomatsakis

[nagisa]

I’d suggest adding a Pass::should_run(stuff) -> bool. We previously had no use-case for such a method, which is why it does not exist currently, but somebody (…ehem, me…) foresaw such use case and left a useful comment.

[scottcarr]

Thanks @nagisa. I took out the O(n^2) cases. For should_run I didn't implement it, but it probably does make some sense for passes to not enable/disable themselves.

[nikomatsakis]

can you leave a comment as to why we do this if -- iirc, otherwise this triggers in constants. Seems like this may be just a temporary limitation, if we improve our constant handling a la miri.

[nikomatsakis]

OK, so I left some nits, but it seems good other than those. r=me when the nits are addressed.

One other question: can you test this using your MIR optimization testing code?

[scottcarr]

I think I'd prefer to open a FIXME issue

I created issue #35186

[nikomatsakis]

Nit: "#35186" makes for easier searching, I think

[nikomatsakis]

@bors r+

[bors]

📌 Commit d918c99 has been approved by nikomatsakis

[bors]

⌛ Testing commit d918c99 with merge 9478922...

[bors]

💔 Test failed - auto-win-msvc-64-opt-no-mir

[alexcrichton]

@bors: retry

• mk: Only pass -Zorbit=off in stage1/2 #35187

[arielb1]

I am worried that this may be a pessimization for newtype structs, because it forces them to memory.

[eddyb]

@arielb1Pair is probably more affected by this atm (as it gets non-memory field access).
However, I think the solution here will involve a combination of newtype unpacking and MIR SROA.

[arielb1]

The problem is that an SSA-value pair/newtype constructor is a no-op at the LLVM level, while a inner-field write, like tmp0.0 = Foo; call Bar(tmp0); is more complicated to handle.

However, that looks like a complication that can be handled at the MIR trans level.

[scottcarr]

It seems to me that we could imagine cases where we don't want to deaggregate, but its not completely clear what those are or if they would be handled by the deaggregator or MIR trans. I opened an issue #35259 to discuss this.

[nikomatsakis]

Given that this won't even be enabled anyway, seems like we can continu to hack on the "when to trigger it" heuristics, so I won't have that block landing!

@bors r+

[bors]

📌 Commit 06acf16 has been approved by nikomatsakis

[bors]

⌛ Testing commit 06acf16 with merge e804a3c...

[bors]

☀️ Test successful - auto-linux-32-nopt-t, auto-linux-32-opt, auto-linux-64-cargotest, auto-linux-64-cross-freebsd, auto-linux-64-debug-opt, auto-linux-64-nopt-t, auto-linux-64-opt, auto-linux-64-opt-no-mir, auto-linux-64-opt-rustbuild, auto-linux-64-x-android-t, auto-linux-cross-opt, auto-linux-musl-64-opt, auto-mac-32-opt, auto-mac-64-opt, auto-mac-64-opt-rustbuild, auto-mac-cross-ios-opt, auto-win-gnu-32-opt, auto-win-gnu-32-opt-rustbuild, auto-win-gnu-64-opt, auto-win-msvc-32-opt, auto-win-msvc-64-cargotest, auto-win-msvc-64-opt, auto-win-msvc-64-opt-no-mir, auto-win-msvc-64-opt-rustbuild
Approved by: nikomatsakis
Pushing e804a3c to master...