ConstraintAnalysis: Add conditional propagation by kripken · Pull Request #8867 · WebAssembly/binaryen

kripken · 2026-06-25T17:26:53Z

When we see an if, br_if, etc., we can propagate the condition along the
true branch, and its negation along the other.

tlively

Comments on code.

tlively · 2026-06-25T22:54:59Z

I just realized that there is probably a bug with constraints that compare two locals, e.g. x == y. When there is a set to x, that constraint will be removed and possibly replaced with a new constraint. But when there is a set to y, I believe we still keep the x == y constraint even though it may no longer be correct.

tlively · 2026-06-25T23:04:08Z

+        ;; We can infer 1 here.
+        (drop
+          (ref.is_null
+            (local.get $param)


It would be even better if we propagated values when we have inferred equality constraints. Then follow-on optimizations would be able to handle not just ref.is_null, but also things like casts.

I'm not sure what you mean here, can you elaborate?

I think we can add cast support later in a simple way, using a new abstract operation "is subtype of". (Though I am not sure how important this is)

If we have an x == null constraint, then instead of optimizing (ref.is_null (local.get x)) => (i32.const 1), we can optimize (local.get x) => (ref.null none).

Then follow-up optimization in other passes will be able to optimize much more than just a parent ref.is_null.

tlively · 2026-06-25T23:07:22Z

Another idea: in traps-never-happen mode, we could actually propagate constraints backward from conditions where one arm is post-dominated by an (unreachable).

kripken · 2026-06-25T23:17:41Z

I just realized that there is probably a bug with constraints that compare two locals

Correct, all inter-local operations are not quite right yet. That's on my list of next PRs here.

kripken · 2026-06-25T23:18:51Z

Another idea: in traps-never-happen mode, we could actually propagate constraints backward from conditions where one arm is post-dominated by an (unreachable).

Interesting... we can only do it one branch back, but that might be useful already. I'll add a TODO

tlively · 2026-06-25T23:44:16Z

Not just one branch back!

log(x <= 10 && x >= 0) ;; optimizable to log(1) in TNH
... arbitrary stuff that doesn't modify x ...
if c
  if x > 10:
    unreachable
else
  if x < 0:
    unreachable

kripken · 2026-06-25T23:50:48Z

Not sure that works:

;; counterexample values
x = 100
c = 0

;; rest of testcase is unchanged
log(x <= 10 && x >= 0)
if c
  if x > 10:
    unreachable
else
  if x < 0:
    unreachable

Execution here goes into the else if the first if. x == 100, so we don't trap. And that proves x >= 0 earlier. But nothing proves x <= 10, which is in fact false. We therefore cannot infer that 1 is logged.

(TNH only applies on paths the code actually traverses: the guarantee is "the program, in practice, does not trap")

tlively · 2026-06-26T00:05:37Z

Oh yeah, sorry, that example was bogus. Here's one that isn't bogus.

log(x) ;; Optimizable to log(1) in TNH
if x < 1:
  unreachable
if x > 1:
  unreachable

kripken · 2026-06-26T00:14:02Z

That one works, yeah, but it is not easy to prove that. It depends on how the conditions relate:

log(x)
if y:        ;; these two lines changed
  return     ;;
if x > 1:
  unreachable

Now nothing can be inferred for the x in log(x), not even that x <= 1.

tlively · 2026-06-26T00:48:39Z

The backward flow you need is similar to the forward flow. The initial state is bottom for each block ending in unreachable (or at which a contradiction is discovered during the forward flow) and top at the end of other exit blocks (if you are not interleaving it with the forward flow). Then you flow backward. Branch conditions are OR'd into the predecessor blocks instead of AND'd into successor blocks. If we follow the C/C++ model, some care needs to be taken around calls and atomic operations because they are allowed to happen in loops that may be followed by unreachables.

kripken · 2026-06-26T17:31:58Z

Yes, that sounds right. Though the ORing will in generally stop working after one branch, unless we get lucky...

tlively · 2026-06-26T19:03:29Z

+//  * If a local is unusable - a non-nullable local before any set - then it is
+//    marked as being able to prove nothing. (We could also mark this as a
+//    contradiction, but both apply - we can indeed prove nothing, as the IR
+//    disallows any uses of it - and avoiding a contradiction avoids confusion
+//    with the case of the basic block being unreachable.)


I see, we can model uninitialized non-nullable locals as having any value instead of having no value because they will always be initialized before they are used anyway; their initial value is moot.

And modeling them that way lets us say that a block is unreachable iff any of the local constraints is bottom. Makes sense!

tlively · 2026-06-26T19:09:26Z

+    // Everything starts unreachable until we reach it in the flow.
+    for (auto& block : basicBlocks) {
+      block->contents.startConstraints.unreachable = true;
+    }


Let's just make this the default state for BasicBlockConstraintMap so we don't need to initialize it separately.

tlively · 2026-06-26T20:07:09Z

+    auto iter = other.map.find(local);
+    if (iter == other.map.end()) {
+      // When an entry is missing in one of the two, it means we can prove
+      // nothing there, which means we can prove nothing in the result.
+      constraints.setProvesNothing();
+    } else {
+      // This local appears in both. OR it.
+      constraints.approximateOr(iter->second);
+    }


Suggested change

auto iter = other.map.find(local);

if (iter == other.map.end()) {

// When an entry is missing in one of the two, it means we can prove

// nothing there, which means we can prove nothing in the result.

constraints.setProvesNothing();

} else {

// This local appears in both. OR it.

constraints.approximateOr(iter->second);

}

constraints.approximateOr(other.get(local))

tlively · 2026-06-26T20:10:32Z

+  if (combined.provesNothing()) {
+    // When we prove nothing, we leave the entry empty.
+    map.erase(index);
+    return;
  }


This can just be an assert(!combined.provesNothing()), since anything AND'd with a single constraint must not be an empty constraint set.

tlively · 2026-06-26T20:15:24Z

-      } else if (LiteralUtils::canMakeZero(type)) {
-        // We have a default value.
+      if (type.size() == 1 && LiteralUtils::canMakeZero(type)) {
+        // We have a default value, so we can prove something.


Please add a comment here about how we are counterintuitively modeling non-nullable locals as having any value instead of no value.

tlively · 2026-06-26T20:20:12Z

+    // We pass the next function the index of the successor among the others.
+    assert(succ == pred->out[0] || succ == pred->out[1]);
+    auto succIndex = succ == pred->out[1] ? 1 : 0;


We wouldn't need to calculate the index like this if we just started with an indexed for loop instead of a range-based for loop over the successors when we process work list items.

tlively · 2026-06-26T20:21:49Z

    } else {
-      // It must be the ifTrue.
-      assert(succ == predOut[0]);
+      assert(succIndex == 0);


We can drop the else and just assert(succIndex < 2) at the beginning.

tlively · 2026-06-26T20:23:38Z

-                       BasicBlock* succ,
-                       const BasicBlockConstraintMap& predEnd,
-                       If* iff) {
+  std::optional<LocalConstraint> getConstraintsFromIf(Index succIndex,


The nittiest of nits, but I would have expected the index to be the second argument for these functions, not the first.

tlively · 2026-06-26T20:25:36Z

-                           const BasicBlockConstraintMap& predEnd,
+  // Gets branch constraints using a successor index and a parsed constraint.
+  std::optional<LocalConstraint>
+  getConstraintsFromParsed(Index succIndex,


I don't think this function is adding much anymore. Let's inline it into its callers. (This will simplify getContraintsFromBreak in particular.)

tlively · 2026-06-26T20:28:53Z

+        ;; We can infer 1 here.
+        (drop
+          (ref.is_null
+            (local.get $param)


If we have an x == null constraint, then instead of optimizing (ref.is_null (local.get x)) => (i32.const 1), we can optimize (local.get x) => (ref.null none).

Then follow-up optimization in other passes will be able to optimize much more than just a parent ref.is_null.

kripken added 30 commits June 3, 2026 14:09

work

da40546

work

ddc615e

work

2707bb1

format

6390870

work

3cedbcf

work

f54afaa

work

8071200

work

b550c4d

work

b1aedcf

work

0bc8d2e

work

61fc656

work

3a3970b

work

8a6d355

work

562872d

go

d296092

go

a46436f

go

413f4e8

go

817a9ca

go

c14b3b9

work

35329c8

go

1dfe44c

f

6e6d06e

go

c9f67d1

go

5f1fdc8

go

c339b79

go

d673317

go

c4321a9

go

260fb83

go

4fe70e3

go

c0d19d9

kripken added 8 commits June 25, 2026 08:50

poset

a2ddb41

rewrite entry values

39c5412

rewrite entry values

7c43f4d

Merge branch 'constraint' into constraint.2

9f3e666

fix

e2db3de

fix

df9f584

Merge branch 'constraint' into constraint.2

25f84b5

merge

5918f00

kripken requested a review from tlively June 25, 2026 17:26

kripken requested a review from a team as a code owner June 25, 2026 17:26

compiler.errar

3744ece

tlively reviewed Jun 25, 2026

View reviewed changes

Comment thread src/ir/abstract.h Outdated

Comment thread src/ir/constraint.cpp

Comment thread src/passes/ConstraintAnalysis.cpp Outdated

Comment thread src/passes/ConstraintAnalysis.cpp Outdated

simplify negation

bdc0e69

tlively reviewed Jun 25, 2026

View reviewed changes

kripken added 4 commits June 26, 2026 11:49

refactor to a clearly-defined BasicBlockConstraintMap&

525bbb7

format

34db73c

simplify branching APIs

d5b9de6

add suggested test

33835ec

tlively reviewed Jun 26, 2026

View reviewed changes

Uh oh!

Conversation

kripken commented Jun 25, 2026

Uh oh!

tlively left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

tlively commented Jun 25, 2026

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

kripken Jun 26, 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!

tlively commented Jun 25, 2026

Uh oh!

kripken commented Jun 25, 2026

Uh oh!

kripken commented Jun 25, 2026

Uh oh!

tlively commented Jun 25, 2026

Uh oh!

kripken commented Jun 25, 2026

Uh oh!

tlively commented Jun 26, 2026

Uh oh!

kripken commented Jun 26, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

tlively commented Jun 26, 2026

Uh oh!

kripken commented Jun 26, 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!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

kripken Jun 26, 2026 •

edited

Loading

kripken commented Jun 26, 2026 •

edited

Loading