Skip to content

New pass: PropagateStructGets - #9271

Open
kripken wants to merge 59 commits into
WebAssembly:mainfrom
kripken:psgs
Open

kripken wants to merge 59 commits into
WebAssembly:mainfrom
kripken:psgs

Conversation

@kripken

@kripken kripken commented Oct 16, 2026

Copy link
Copy Markdown
Member

Our main escape analysis pass, Heap2Local, does not handle overlapping
live ranges, things like this:

x = new Foo(42);
if (condition) x = new Foo(1337);
bar(x.value, x.value);

More than one allocation is being read from in those x.value operations,
so Heap2Local sees the uses are not "exclusive", and it gives up.

Handling live ranges, sort of like liveness of locals for register allocation /
local coalescing, is possible, but quite complex. However, the pattern
above can be optimized in another way, which this new pass handles:
when the reference is always read from (using struct.get, which is the
.value operations above), then we can just shift from using the reference
to using data:

x_value = (new Foo(42)).value;
if (condition) x_value = (new Foo(1337)).value;
bar(x_value, x_value);

We store the data in a new local x_value, and that is all we need.

That is, this pass handles a situation that is more restricted than
Heap2Local, in that it doesn't do complex analysis of control flow
and handling of ref.eq and such, but it is more general in that it
can handle overlapping live ranges in a trivial way.

Fixes #8641 , a Dart testcase, and I saw this helps real-world binaries from
Kotlin and Java too - this is a common pattern.

@kripken
kripken requested a review from tlively October 16, 2026 20:36
@kripken
kripken requested a review from a team as a code owner October 16, 2026 20:36
Comment on lines +54 to +56
// Heap2Local cannot optimize this due to the overlapping live ranges (it sees
// the x.value operations are not exclusive to any single allocation). But this
// pass can optimize into this:

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The reason Heap2Local can't handle this is because it only analyzes a single allocation at a time, rather than doing a single analysis phase covering all allocations in the function. This design limitation is also responsible for significant additional complexity in the pass. Have you experimented with fixing Heap2Local to analyze all allocations at once?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes,

Handling live ranges, sort of like liveness of locals for register allocation / local coalescing, is possible, but quite complex

I had Gemini get this fully working, then simplify as much as it (and I) could, and it was... not pretty.

Basically you need to layer an additional LivenessAnalysis in Heap2Local, just adding a lot of complexity. Sadly it can't replace any existing part. It is even harder than a normal locals-based liveness because we must track allocations as they live in locals, but also as they flow - e.g. two allocations flowing through arms of the same If.

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Optimization issue where allocation is not eliminated

2 participants