New pass: PropagateStructGets by kripken · Pull Request #9271 · WebAssembly/binaryen

kripken · 2026-10-16T20:36:29Z

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.

tlively · 2026-10-16T20:47:46Z

+// 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:


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?

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.

tlively · 2026-10-19T21:52:58Z

+    return std::make_unique<PropagateStructGets>();
+  }
+
+  // Track the number of gets for each local, so that we can see if all gets are


Suggested change

// Track the number of gets for each local, so that we can see if all gets are

// Track the number of gets for each local, so that we can see if all the local.gets are

tlively · 2026-10-19T21:54:20Z

+  // The sets for each local index.
+  std::unordered_map<Index, std::vector<Expression**>> sets;
+
+  // The parent struct.gets for each local index's gets.


Suggested change

// The parent struct.gets for each local index's gets.

// The parent struct.gets for each local index's local.gets.

I want to keep the different gets as separate as possible :)

tlively · 2026-10-19T21:55:16Z

+  // The parent struct.gets for each local index's gets.
+  std::unordered_map<Index, std::vector<StructGet*>> getParents;
+
+  // The parent struct.get for each tee.


It would be good to briefly say what happens when a local.get or local.tee does not have a parent struct.get.

tlively · 2026-10-19T21:57:32Z

+    // Avoid unreachable code, and leave atomic operations for now TODO
+    if (curr->type == Type::unreachable ||
+        curr->order != MemoryOrder::Unordered) {


There should be no need to leave atomic struct.gets for later. If the accessed allocations don't escape, they can't be part of any synchronization between threads, so they can be optimized just like non-atomic accesses.

Also, if we can optimize structs that don't come from allocations, this would still be valid when all their fields are immutable. Immutable fields cannot participate in cross-thread synchronization.

tlively · 2026-10-19T22:00:25Z

+      return;
+    }
+
+    auto* module = getModule();


Suggested change

auto* module = getModule();

auto* wasm = getModule();

Maybe there's some more nuanced pattern about where we use module vs wasm, but my impression is that we generally use wasm in passes, at least.

tlively · 2026-10-19T22:23:11Z

+          if (teeIt == teeParents.end()) {
+            // This tee does not feed into a struct.get, so the allocation(s)
+            // might escape.
+            ok = false;
+            break;


This also could have been checked directly via an ExpressionStackWalker rather than after the fact.

tlively · 2026-10-19T22:29:46Z

+      // Each used field's value must not change between the local.set and
+      // local.get: either the field is immutable, or every set writes a fresh
+      // struct.new that only ever flows into this local's struct.gets. (Note


How could the field's value change, given that we have ruled out struct.sets? Also, it is not clear which local.set and local.get this refers to.

Gemini says we've only ruled out struct.sets through this particular local, but aliasing could allow other sets to slip through. It would be good to clarify that in the comment.

tlively · 2026-10-19T22:32:28Z

+      //   bar(x_value, x_value);
+      //
+      // Note how the `.value` (the struct.get) happens *before* `foo()`,
+      // after the optimization, so we may have moved a trap around here. It is


Don't we know the local.set values always come from allocations, though?

Gemini says the pass also supports structs coming from parameters or calls as long as their fields are all immutable. It would be good to update the top-level comment to reflect that.

tlively · 2026-10-19T22:33:51Z

+
+  void visitTry(Try* curr) { hasTry = true; }
+
+  void visitFunction(Function* func) {


It would be nice to break this up into helper functions. It's huge.

tlively · 2026-10-19T22:36:15Z

+    ;; As above, but the immutable field has a non-nullable reference type
+    ;; ((ref struct)). The optimizeed local uses a nullable type (since it is
+    ;; not dominated in the spec's sense by sets), and we add ref.as_non_null
+    ;; on the tees and get so validation succeeds across blocks.


"optimizeed" => "optimized"

kripken added 30 commits October 15, 2026 14:00

start

66f0b3a

form

e69921a

commentses

324b32e

commentses

8c19fde

work

d39f84e

work

36fed8f

work

549a1f0

work

5414281

work

273f8e2

work

3d9e22f

work

18790e7

work

bbed88f

work

88d62e1

work

63b9bea

work

03bd309

work

110938c

work

b5a8718

work

6da0c54

work

15be564

work

8b0309e

work

ff69080

work

0c2a6d2

fuzz

84bbb61

help

86c90f3

work

934598d

work

931dd17

work

7748a47

work

39bb1c9

work

7c504b3

work

53a7f35

kripken added 21 commits October 16, 2026 11:20

work

bd01685

work

6117c65

work

6b93c8b

work

cde69f1

work

9b6d881

work

71fb51c

work

621cb26

work

029ab8d

work

20ecd6b

work

742e9de

work

135ae8c

work

e4c366d

work

608541c

work

71d5688

work

9ec8847

work

5900853

work

e536c39

work

f0b6e55

work

5ea5684

work

8810a6d

work

cb1bb8b

kripken requested a review from tlively October 16, 2026 20:36

kripken requested a review from a team as a code owner October 16, 2026 20:36

tlively reviewed Oct 16, 2026

View reviewed changes

kripken added 5 commits October 16, 2026 16:01

fix the case of a param's unknown value, we should not optimize there

6b59410

add subtyping test

c09bd78

fix pops

4159305

format

077d48a

fix nullref

ce3e52a

tlively reviewed Oct 19, 2026

View reviewed changes

	// Track the number of gets for each local, so that we can see if all gets are
	// Track the number of gets for each local, so that we can see if all the local.gets are

	// The parent struct.gets for each local index's gets.
	// The parent struct.gets for each local index's local.gets.


		void visitTry(Try* curr) { hasTry = true; }

		void visitFunction(Function* func) {

Conversation

kripken commented Oct 16, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

tlively Oct 19, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

This branch has not been deployed

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

tlively Oct 19, 2026 •

edited

Loading