Combine instructions immediately

[tmiasko]

No description provided.

[rust-highfive]

r? @petrochenkov

(rust-highfive has picked a reviewer for you, use r? to override)

[petrochenkov]

r? @lcnr

[nagisa]

This makes sense to me given the scope of instcombine today, but I imagine this would make it significantly more difficult to instcombine multiple statements into one if we ever get to the point of wanting to do so.

[lcnr]

hmm, what @nagisa said makes sense to me.

Don't really have an opinion on if we should land this PR and am not involved enough to decide.

r? @nagisa feel free to reassign to someone else from wg-mir-opt though

[nagisa]

Thinking about it a little more:

Given the structure of the MIR, having to use the same pass for both multi-statement and single-statement combines is probably an overall negative, mostly because there is likely a significant inherent cost associated with maintaining state for inst-combines that operate over multiple MIR statements (in LLVM its fine because its all pointers and referencing instructions is very cheap due to its SSA nature).

So, it would make sense to me to have a separate pass for multi-statement instcombines once we start thinking about implementing those. On the other hand, in that world you'd probably want to run the two instcombines passes in a fixpoint anyway… so 🤷

cc @oli-obk

[tmiasko]

Non-local transformation would require a different approach, but as long as we don't make them this approach has a benefit of making it clear that one transformation cannot invalidate another, since transforms are immediate and stateless.

This is relatively trivial amount of code so we can always change this as a need arises.

[bors]

☔ The latest upstream changes (presumably #80865) made this pull request unmergeable. Please resolve the merge conflicts.

[nagisa]

@bors r+

[bors]

📌 Commit 508eec4 has been approved by nagisa

[nagisa]

@bors rollup=never

[bjorn3]

Should this get a perf run?

[nagisa]

I'm pretty confident this will be a net win due to the new code just doing less work walking the MIR structure. I still made it rollup=never so that we do eventually see the perf results once this lands, though.

[bors]

⌛ Testing commit 508eec4 with merge f2de221...

[bors]

☀️ Test successful - checks-actions
Approved by: nagisa
Pushing f2de221 to master...

[bjorn3]

This is a mixed speedup (up to 0.6%) and slowdown (up to 1.3%): https://perf.rust-lang.org/compare.html?start=bbc01bb624a960533e049fdb98d0489ff2a8de06&end=f2de221b0063261140a336c448bf1421170c9a74&stat=instructions%3Au

[tmiasko]

The perf results should show measurement error based on historical data, they are quite misleading otherwise. For example ctfe-stress-4-check which shows 1.3% slowdown never executes this code. Similarly debug and opt variants of this benchmark execute it only once on a MIR body with a single statement.