ConstraintAnalysis: Optimize local.get by kripken · Pull Request #9136 · WebAssembly/binaryen

kripken · 2026-09-22T20:15:25Z

E.g.

(if
  (local.get $x)
  (then ..)
  (else
    ..(local.get $x)..   ;; this must be 0.
  )
)

This removes the "markRelevant" logic that tried to only track locals
that have interesting operations on them that we can optimize,
because now anything with a local.get might get optimized - which
is pretty much anything.

This does make the pass significantly slower, unfortunately, around
30% or so, and this was one of our slower passes. I'm looking into
speedups to land after this to mitigate that, but this does look useful
enough: this increases the amount of things we optimize by a
substantial amount. On one large Dart testcase I saw a total binary
size reduction of 0.3%. Overall this seems like the right tradeoff
for a pass that only runs in -Os/-O3+.

Some existing tests needed adjustment, as constants are now
propagated in cases that can be confusing.

tlively · 2026-09-22T23:17:15Z

+      auto oldType = (*currp)->type;
+      if (!Type::isSubType(rep->type, oldType)) {
+        // The value we know must exist here is impossible, which means it was
+        // cast in a way that traps at runtime. This code is unreachable.
+        rep = Builder(*getModule()).makeUnreachable();
+        refinalize = true;
+      } else if (rep->type != oldType) {
+        // We are refining.
+        refinalize = true;
+      }


Should we move this logic into optimizeLocalGet so this loop can be responsible for nothing but performing the replacements? That will keep all the optimization logic together in one place.

Good idea, done. This does mean passing around refinalize but it does seem nicer overall.

tlively · 2026-09-22T23:18:57Z

Does ctor-eval run optimizations by default? Is that why there is a change here?

Yes, after we eval code in a function, we run default opts immediately as a followup. (To save the user needing to do the obvious wasm-opt call)

tlively · 2026-09-22T23:20:18Z

-;; CHECK-NEXT:   (local.get $0)
-;; CHECK-NEXT:   (local.get $0)
-;; CHECK-NEXT:  )
+;; CHECK-NEXT:  (i32.const 84)


Are we optimizing tuple-typed locals? If so, is that intentional?

We don't optimize them directly (no parsing support for tuples), but if TupleOptimization broke such a local into normal ones, we can handle those.

tlively · 2026-09-22T23:45:05Z

+    ;; The condition here ends up comparing $x to itself. That is normally 1,
+    ;; but not with a nan. We do not optimize floats for this reason (without
+    ;; --fast-math, see constraint-analysis-float.wast).


I guess we could still optimize in cases where we know the relevant values cannot be NaNs. Like if we had an f64.const 1 below, we would know that the LHS and RHS of the f64.eq cannot be NaN, so we could still optimize according to the normal math rules.

Yes, there is definitely more we can do for floats here. I have some TODOs that I hope to get to.

tlively · 2026-09-22T23:45:49Z

+    ;; A non-null value, like an internalized string, is not optimized (we could
+    ;; emit an any.convert_extern of a strong.const, but it increases size, so
+    ;; we leave this for passes like Precompute and GUFA).
+    ;; TODO: should we optimize this?


Probably; all the strings constants should be deduplicated during string lowering anyway.

Hmm, good point. Anyhow, let's consider this later?

tlively

LGTM % last comment.

tlively · 2026-09-23T18:51:13Z

  Expression* optimizeLocalGet(Expression** currp,
-                               const BasicBlockConstraintMap& constraints) {
+                               const BasicBlockConstraintMap& constraints,
+                               bool& refinalize) {


This is a function-parallel pass, so we should be able to just track refinalize as a member of the pass class rather than passing it around.

Good point, done.

kripken · 2026-09-23T20:01:30Z

Will only land this after landing some speedups first, to avoid a big slowdown in the middle.

…nt-locals-detection scheme - all we do is operate on all locals, except ones of the wrong types - we don't need to carefully check if we detected the right locals as relevant.

kripken · 2026-09-24T17:35:48Z

Speedups landed. With them + this PR, things are faster than before!

kripken added 30 commits September 17, 2026 13:43

go?

f39cbc5

work

eb1cf7e

work

6e64e10

work

fbf0903

work

eb62916

work

f9ea341

work

8d3cac8

fix

1ca0357

fix

f23e45c

work

9262af5

work

7ce181c

work

0eb6ad3

work

87922a3

work

02b062f

work

ebd23e6

work

6e56a0e

work

783f44a

work

6db5f6a

work

c8a3ffb

Merge remote-tracking branch 'origin/main' into c.get

9b66ee5

work

8e3495c

work

5795eec

work

03126ad

work

0782b34

work

e79ade7

work

9fe588d

work

68e9e5c

work

96f839c

work

fca9397

work

65216d7

kripken requested a review from tlively September 22, 2026 20:15

kripken requested a review from a team as a code owner September 22, 2026 20:15

kripken added 4 commits September 22, 2026 14:09

Merge remote-tracking branch 'origin/main' into c.get

4cf0949

update existing tests

d3ce163

another update

ceb6e9a

another update

d590467

tlively reviewed Sep 22, 2026

View reviewed changes

kripken added 3 commits September 23, 2026 11:15

merge

f08d719

fix.merge

650e5d8

feedback: refactor builder stuff into OptimizeLocalGet

d29b82c

tlively approved these changes Sep 23, 2026

View reviewed changes

refactor refinalize

737b2d0

[NFC] remove some dead code: now that we do not have a complex releva…

c4eb348

…nt-locals-detection scheme - all we do is operate on all locals, except ones of the wrong types - we don't need to carefully check if we detected the right locals as relevant.

kripken merged commit b40790f into WebAssembly:main Sep 24, 2026
16 checks passed

kripken deleted the c.get branch September 24, 2026 17:36

Conversation

kripken commented Sep 22, 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!

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 left a comment

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 commented Sep 23, 2026

Uh oh!

kripken commented Sep 24, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants