Repository navigation
[MIR] when should we not deaggregate? #35259
Description
Activity
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
Pairstuff in the translator as well, but would need a good heuristic to not become a pessimisation itself.That being said, I feel like LLVM should be more than capable to handle such case quite quickly by itself.
@nagisa There's 2 reasons SRoA isn't enough to replace
Pair: fat pointers usePairandCheckedBinOpproduces 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".
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 removeAggregatefrom MIR.
(which we can do in a borrowck-friendly way viaSetDiscriminant(x, 0)on all aggregates)
#35168 adds the capability of deaggregating structs like:
Into:
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.