Make br_if with a value's type match the spec #6390

kripken · 2024-03-08T23:39:37Z

Previously br_if with a value had the same type as the value, but the spec
says it should be the type of the block it targets, which might be less refined.
Context:

WebAssembly/gc#516 (comment)

This is unfortunate for Binaryen as the value is right there in our IR, while
looking up the block's type is more effort. I measure a 1.5% slowdown in
building a J2Wasm testcase with this. There do not seem to be downsides
to the output, but that is just because the value output of br_if is practically
never used outside of fuzz testcases and exploits.

Summary of the necessary changes for this:

Adjust validator to allow the spec form only.
Add optional Type param to the C API to create a Break.
ReFinalize may do another pass if it ends up updating br_ifs - we can no
longer just do a simple forward pass here, as block changes go "backwards"
to br_ifs. In practice I think that should be rare (on J2Wasm I see only a
3 times where an extra iteration is needed when running -O3).
Update br_if types in the few passes that modify br_if values or add
values or conditions to brs, including Heap2Local, RemoveUnusedBrs,
SimplifyLocals.
RemoveUnusedBrs also must be careful not to un-refine block types. It
used to do that, and they generally ended up refined later anyhow, but now
this would be a danger (they would unrefine the br_if, which might break).
The parsers must provide br_if types during construction.
Add Type.containsRef() helper.

tlively

I hadn't thought about the fact that calculating precise types requires a fixed point computation after this fix. Maybe we should press a little harder on this issue after all.

tlively · 2024-03-09T00:00:47Z

src/ir/ReFinalize.cpp

+    // After that walk we may have br_ifs in need of refinalization. Update them
+    // and refinalize again, as they may enable further improvements. This is in
+    // theory very slow, but in practice one or two cycles suffices and we can't
+    // try to be frugal here as must propagate all the possible improvements, or


Suggested change

// try to be frugal here as must propagate all the possible improvements, or

// try to be frugal here as we must propagate all the possible improvements, or

tlively · 2024-03-09T00:35:20Z

src/passes/RemoveUnusedBrs.cpp

+                                 if (auto* ret = curr->dynCast<Return>()) {
+                                   value = ret->value;
+                                 } else {
+                                   value = curr->cast<Break>()->value;


This can never be a Switch or any other branching instruction?

tlively · 2024-03-09T00:38:03Z

src/passes/RemoveUnusedBrs.cpp

+// to GC). This also calls finalize as needed, so that after calling it the
+// br_if type is fully updated.
+using BlockTypeMap = std::unordered_map<Name, Type>;
+static void updateBrIfType(Break* br, const BlockTypeMap& blockTypeMap) {


Is this to avoid having to do a full ReFinalize to fix the br_if types? If so, is it really worth the extra complexity?

tlively · 2024-03-09T00:39:26Z

src/passes/RemoveUnusedBrs.cpp

+
+      // Note types of blocks. This parallels the logic in the parent class,
+      // but we do not want to just reuse the data structure there: things may
+      // have changed since then.


Changed since when?

tlively · 2024-03-09T00:46:00Z

src/wasm/wasm-type.cpp

+  if (isTuple()) {
+    for (auto t : *this) {
+      if (t.isRef()) {
+        return true;
+      }
+    }
+    return false;
+  }
+  return isRef();
+}


You can iterate through non-tuple types as well, and the iterator will just dereference to the type itself.

Suggested change

if (isTuple()) {

for (auto t : *this) {

if (t.isRef()) {

return true;

}

}

return false;

}

return isRef();

}

for (auto t : *this) {

if (t.isRef()) {

return true;

}

}

return false;

}

tlively · 2024-03-09T00:52:04Z

src/wasm/wasm-s-parser.cpp

+      // There is no block by that name, so this must target the function scope.
+      // We could also validate that it is in fact the function scope, but the
+      // main validator does that anyhow; all we need here is to generate valid
+      // IR if it is valid.


Although it has been suggested as an extension to the text format, there is not currently a way to use a symbolic name to have a branch target the function scope, so I don't think the old parser needs to (or should be able to) support this case.

tlively · 2024-03-09T00:55:40Z

src/wasm/wasm-validator.cpp

@@ -781,6 +797,11 @@ void FunctionValidator::visitLoop(Loop* curr) {
                    "breaks to a loop cannot pass a value");
    }
    breakTypes.erase(iter);
+
+    // Validate there are no br_ifs with values targeting us.
+    shouldBeTrue(!labelBrIfs.count(curr->name),


Is this not covered by the breakTypes check above?

tlively · 2024-03-09T01:27:35Z

I also just realized that this refinalization algorithm does not find the smallest fixed point of the types (i.e. the most refined possible block and br_if types).

Consider this program:

(type $A (sub (struct)))
(type $B (sub $A (struct)))

(func (result (ref $A))
 (block $a (result (ref $A))
  (br_if $a
   (struct.new $B)
   (i32.const 0)
  )
 ) 
)

If I'm not mistaken, ReFinalize will not be able to improve the type of the block because it calculates the type of the block as the LUB of the sent values of the br_if and the fallthrough value, which is (ref $A). It will also never improve the type of the br_if.

The fix would be to do the first ReFinalization walk with the old behavior of setting the br_if type equal to its value's type, then doing subsequent iterations with the new behavior to relax the types up to the smallest fixed point.

kripken · 2024-03-09T03:24:56Z

The fix would be to do the first ReFinalization walk with the old behavior of setting the br_if type equal to its value's type, then doing subsequent iterations with the new behavior to relax the types up to the smallest fixed point.

Good point about this not necessarily reaching the optimal point. And, interesting idea to solve it.

Thinking about that, perhaps another option is to first walk with the old behavior, and then to add casts as necessary afterwards, without any further iterations? That is, any br_if that we must force to be a less-precise type than it "wants" to be would be cast so that it does flow out the type it "wants." Adding casts is not ideal, but that situation is quite rare.

tlively · 2024-03-09T06:06:22Z

Oh yeah, adding casts seems fine, too. It gets back all of the type precision at the cost of having to execute the casts at runtime. How much do you think that would simplify this PR beyond ReFinalize itself?

Since following the spec rules has more downsides than I had anticipated, I also started pushing more to get them changed: WebAssembly/gc#516 (comment).

kripken · 2024-03-09T06:26:59Z

How much do you think that would simplify this PR beyond ReFinalize itself?

Hmm, good question. I think adding the casts would remove a little bit of complexity (while not adding much extra tracking logic). But that would still leave 99% of the complexity in this PR. Good idea to discuss spec options.

tlively · 2024-03-09T07:18:32Z

If we are able to change the spec, then we'll have to fix our handling of local.tee instead. local.tee would no longer be exactly equivalent to a local.set + local.get. IIRC, you did some experiments with that a while ago and decided that wouldn't be a big problem, right?

kripken · 2024-03-09T18:58:47Z

Yes, updating local.tee would require some work but we thought it was not a big burden: #3704 (it's possible changes since then make things worse but I doubt it).

Reading that and WebAssembly/gc#201 again, it's hard not to see how we seem to keep returning to this topic again and again... 😄 🔁

kripken · 2024-05-15T23:28:10Z

Closing in favor of #6510

kripken added 30 commits March 6, 2024 16:31

yolo

fca13ce

fixen

fc943d6

start

e918555

start

0dae960

start

5a0e745

start

25e7485

fix

6bb5d7d

fix

e0118b3

fix

de77ed3

work

e03e9a1

fix

ae58912

update test

ab25bb6

work

bcb3873

fix

e4d2200

fix

09d25bb

format

e08ace4

work

b424067

format

e481b44

fork

ff5391a

work

1ac48b9

horribl

86f487a

fix

f8a177a

typo

49f8dde

changelog

beee1fb

work

836ed0f

work

ca0ee19

fix

7bb4aa5

work

caf070d

work

528ad95

work

b7db67e

kripken added 16 commits March 8, 2024 10:59

fix

e571973

Merge remote-tracking branch 'origin/main' into br_if

8e2bf15

test

31d70a1

fix

4377a8d

test

6d14b8a

fix

eda3d26

fix

50f3dd2

fix

ea7b3fd

fix

ee48896

fix

d6ff014

fix

8b32aac

fix

b274bbb

fix

b4ebae9

fix

b947d7c

fix

84d9851

format

041dfd1

kripken requested a review from tlively March 8, 2024 23:39

format

ec3bb17

tlively reviewed Mar 9, 2024

View reviewed changes

conrad-watt mentioned this pull request Mar 19, 2024

[Draft][spec] Improve typing of br_if WebAssembly/gc#532

Open

This was referenced Apr 17, 2024

Run (basic) StackIR optimizations in all binary writes? #6509

Open

Fix binary emitting of br_if with a refined value by emitting a cast #6510

Merged

kripken closed this May 15, 2024

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Make br_if with a value's type match the spec #6390

Make br_if with a value's type match the spec #6390

kripken commented Mar 8, 2024

tlively left a comment

tlively Mar 9, 2024

tlively Mar 9, 2024

tlively Mar 9, 2024

tlively Mar 9, 2024

tlively Mar 9, 2024

tlively Mar 9, 2024

tlively Mar 9, 2024

tlively commented Mar 9, 2024

kripken commented Mar 9, 2024 •

edited

Loading

tlively commented Mar 9, 2024

kripken commented Mar 9, 2024

tlively commented Mar 9, 2024

kripken commented Mar 9, 2024

kripken commented May 15, 2024

	// try to be frugal here as must propagate all the possible improvements, or
	// try to be frugal here as we must propagate all the possible improvements, or

Make br_if with a value's type match the spec #6390

Make br_if with a value's type match the spec #6390

Conversation

kripken commented Mar 8, 2024

tlively left a comment

Choose a reason for hiding this comment

tlively Mar 9, 2024

Choose a reason for hiding this comment

tlively Mar 9, 2024

Choose a reason for hiding this comment

tlively Mar 9, 2024

Choose a reason for hiding this comment

tlively Mar 9, 2024

Choose a reason for hiding this comment

tlively Mar 9, 2024

Choose a reason for hiding this comment

tlively Mar 9, 2024

Choose a reason for hiding this comment

tlively Mar 9, 2024

Choose a reason for hiding this comment

tlively commented Mar 9, 2024

kripken commented Mar 9, 2024 • edited Loading

tlively commented Mar 9, 2024

kripken commented Mar 9, 2024

tlively commented Mar 9, 2024

kripken commented Mar 9, 2024

kripken commented May 15, 2024

kripken commented Mar 9, 2024 •

edited

Loading