[MIR] when should we not deaggregate?

[scottcarr]

#35168 adds the capability of deaggregating structs like:

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

Into:

tmp2.0 = ...
tmp2.1 = ...

But, one could imagine situations where this is counter productive.

It's not clear if this should be handled by the Deaggregator or MIR trans.

[nagisa]

I can’t think of a trivial way to reverse deaggregation, especially after multiple optimisation passes go through the MIR.

The newtype concern raised by Ariel could be easily handled by replacing

tmpx: Newtype(T1, T2, ...);
tmpx.0 = ...;
tmpx.1 = ...;

with

tmpx_1: T1;
tmpx_2: T2; 
tmpx_1 = ...;
tmpx_2 = ...;

(This is probably the same thing as SRoA, which @eddyb mentioned) This likely would allow us to discard some of the Pair stuff in the translator as well, but would need a good heuristic to not become a pessimisation itself.

[nagisa]

That being said, I feel like LLVM should be more than capable to handle such case quite quickly by itself.

[eddyb]

@nagisa There's 2 reasons SRoA isn't enough to replace Pair: fat pointers use Pair and CheckedBinOp produces one. And yes, LLVM can handle most of these by itself anyway.

Newtypes (including those with extra ZST fields) are more relevant because of "zero-cost abstractions".

[Aatch]

@nagisa I think the issue is about not deaggregating in some cases, rather than trying to reverse it.

[eddyb]

I have a prototype of optimizing through fields of locals and it's much more straight-forward to do it after deaggregation than trying to understand the creation of aggregates as a whole.
Feel free to reopen this if anything changes, but we're more likely to remove Aggregate from MIR.
(which we can do in a borrowck-friendly way via SetDiscriminant(x, 0) on all aggregates)

[bjorn3]

#107267 fixed this, right?