Propose 2025h2 goal for MIR move elimination optimization #338
Conversation
|
As previously discussed on Zulip, I have major concerns about the enormous amounts of complexity this adds to the language semantics (not just MIR semantics -- this would be user-visible), and about the impact this has on other MIR opts that will no longer be able to assume that our local variables behave like normal allocations. Cc @rust-lang/opsem |
|
|
||
| The primary goal for the next 6 months is to nail down the new semantics for MIR that will enable move elimination and write and RFC proposing these new semantics. This will primarily involve the language team (specifically the opsem team), but also the compiler team to evaluate the impact of the changes to MIR on the existing MIR optimization framework. | ||
|
|
||
| Once the new semantics are accepted then these would need to be implemented in Miri for checking. Finally, the new MIR optimization pass can be implemented in the compiler. |
There was a problem hiding this comment.
Miri uses a very simple approach for picking the address for allocations, so even if we get these semantics nailed down in MiniRust (which should probably be the first step), it's not clear that there's a good way to implement them in Miri.
There was a problem hiding this comment.
The project goal proposal isn't meant to cover all the details, only give an overview. I am working on a more complete design document that covers all the details.
For this particular case, the addresses of locals are angelically chosen to avoid the same bytes being active in 2 allocations at once. In practice this is only relevant for MIR optimizations; for Miri this means keeping allocations for locals non-overlapping, which is basically what we are already doing.
There was a problem hiding this comment.
The project goal proposal isn't meant to cover all the details, only give an overview.
Yeah, I understand. I just pointed out that Miri is probably not the best vehicle to work out these ideas in more detail. MiniRust should be more suited. A notion of partial deallocation should be fairly easy to add there.
However, if this relies on angelic choice then I'm afraid it's not going to go anywhere. Angelic choice breaks fundamental reordering principles that optimizations rely on (see rust-lang/unsafe-code-guidelines#392). We cannot have angelic choice in MIR semantics. Maybe one day someone can work out a weaker form of angelic choice that does not break reordering, but that will come with some amount of restrictions, and until we know what those restrictions are everything involving angelic choice should be treated as entirely speculative.
Co-authored-by: Ralf Jung <post@ralfj.de>
|
Merging the proposal. We'll get to the merits of the solution and whether to accept this during the goal review. |
This goal intends to add a MIR optimization which eliminates moves (
memcpy) where possible.Rendered