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-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.

Comments added.

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.

We do optimize cases where structs arrive from e.g. parameters, i.e. not allocations that we view. See e.g. the test $set-unknown-immutable. Yes, that depends on immutability, as you said.

Is that enough for atomic synchronization? Would the struct.gets need to be atomic?

Yes, we can still optimize in that case. No, the struct.gets do not need to be atomic.

Is that because a Publish must happen after the immutable field is written at creation?

Added optimizing of atomic operations + tests.

No, it's because cross-thread synchronization requires a release (or stronger) write on one thread that is then read from by an acquire (or stronger) read on another thread. The first half of that cannot happen with an immutable field. The initializing write done by struct.new and friends is not a release write.

So other threads can read immutable fields non-atomically? Immutable writes (i.e. creations) are guaranteed to synchronize without atomics?

Yes, that pattern is safe due to the publish built into struct.new. But the synchronization effect of the publish does not extend to anything besides the fields of the particular published struct.

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.

Added a 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.

Added to the top-level comment to clarify that.

Though this does make me think, should we optimize cases without any allocation? atm we do, and it is not obvious to me if that is helpful or not.

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.

Split up into find-locals-to-optimize and optimize functions. I didn't see other obvious opportunities to split stuff up, as the rest would require a bunch of outparams etc.

Co-authored-by: Thomas Lively <tlively123@gmail.com>

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 9 commits October 16, 2026 13:12

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

Comment thread src/passes/PropagateStructGets.cpp

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

kripken and others added 12 commits October 20, 2026 12:00

Update src/passes/PropagateStructGets.cpp

055481c

Co-authored-by: Thomas Lively <tlively123@gmail.com>

Update src/passes/PropagateStructGets.cpp

77a7b81

Co-authored-by: Thomas Lively <tlively123@gmail.com>

mention what happens when tee/get lack a struct.get parent

06fe0cf

format

32f864a

add test for local.tee unpotimization

e9d4cba

add a testcase for a struct.get child not being a tee or a get

8c1e615

add comment on immutability

055cd52

typo

a8061e0

split up visitFunction

d3b728e

add atomic test 1

bb0a6e5

add atomic test 2

c0e6725

add atomic test 3

0980b29


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

		void visitFunction(Function* func) {

Conversation

kripken commented Oct 16, 2026

Uh oh!

Uh oh!

Uh oh!

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!

kripken Oct 20, 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!

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!

Uh oh!

This branch has not been deployed

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

tlively Oct 19, 2026 •

edited

Loading

kripken Oct 20, 2026 •

edited

Loading