Intrinsic: dead.if.unused by kripken · Pull Request #8268 · WebAssembly/binaryen

kripken · 2026-02-05T16:44:10Z

Based on discussion in

the @binaryen.dead.if.unused code annotation has the meaning that
if the result is unused (dropped), then the code can be considered
dead (no side effects, removable).

This can be used on a function to affect all calls to it, or on specific
call instructions. The optimizer then finds relevant dropped calls and
can remove them (in Vacuum).

Bikeshedding welcome on the name.

tlively · 2026-02-05T19:56:54Z

src/wasm.h

+  // Toolchain hint: If this expression's result is unused, then the entire
+  // thing can be considered dead and removable.
+  // TODO: link to spec somewhere
+  std::optional<std::monostate> deadIfUnused;


Is it really better to use a std::optional rather than bool here? It doesn't look like we take advantage of the uniformity of using std::optional in any way.

I think it's just nice for consistency. Each hint may be present or not, and handling that property uniformly with the same C++ mechanism seems clearer?

If any of the use sites had to change, I would agree. But I'm pretty sure making this a bool is a strict simplification, even if it is obviously different from the other hints. I think "std::optional if there is associated data and otherwise bool" is still a pretty simple guideline.

Fair enough, done.

tlively · 2026-02-05T21:40:10Z

src/passes/Vacuum.cpp

+        auto iter = annotations.find(target);
+        if (iter != annotations.end()) {
+          auto& annotation = iter->second;


It looks like it would be useful to have a func->getAnnotation(curr) helper of some sort to avoid mucking around with map lookups at every callsite. It could even return an empty annotations object when there is no annotation to avoid all branching logic in the caller.

It also seems somewhat magical that querying with a null expression gets the function annotations. I think ideally we would have a separate helper for that.

Added a nicer helper now.

tlively · 2026-02-05T21:46:42Z

src/passes/Vacuum.cpp

+      };
+
+      // Look for an annotation on the call.
+      if (checkDeadIfUnused(getFunction(), call)) {


I'm imagining that this could be something like this:

Suggested change

if (checkDeadIfUnused(getFunction(), call)) {

if (getFunction()->getAnnotations(call).deadIfUnused) {

Yeah, that's a good idea... I'll do some experimenting with a nicer API along those lines.

tlively · 2026-02-05T21:47:15Z

src/passes/Vacuum.cpp

+      // Check on the called function, if it exists (it may not if the IR is
+      // still being built up).


When are we Vacuuming IR that is not yet constructed?

In wasm2js we apparently have situations where we optimize "partial" code, before the module is complete. We used to do that in asm2wasm back in the day (compile one function before later functions were even parsed) but we got rid of asm2wasm.

Do you think it would be possible to have wasm2js stop doing that?

It might not be trivial. Looks like the place is processStandaloneFunction which tests use to just handle a function outside of a module. The wasm2js testing stuff is... not simple, unfortunately.

tlively · 2026-02-05T21:48:23Z

src/passes/Vacuum.cpp

+      // Check on the called function, if it exists (it may not if the IR is
+      // still being built up).
+      if (auto* target = getModule()->getFunctionOrNull(call->target)) {
+        if (checkDeadIfUnused(target, nullptr)) {


And I'm imagining something like this here:

Suggested change

if (checkDeadIfUnused(target, nullptr)) {

if (target->getFuncAnnotations().deadIfUnused) {

tlively · 2026-02-05T21:50:28Z

test/lit/dead-if-unused.wast

Should we check round-tripping of the function-level annotation as well?

tlively · 2026-02-05T21:56:28Z

test/lit/passes/vacuum-dead-if-unused-func.wast

@@ -0,0 +1,88 @@
+;; RUN: wasm-opt -all --vacuum %s -S -o - | filecheck %s


Can we autogenerate the output for this one?

It looked into this a little but it would be a huge refactoring of the update script. The issue is that module-level things like functions are all tracked by name, but this would not be a named thing, so a very different regex is needed, and different tracking to match it up to the right thing in the output. I did some experimentation, but it got very messy... Though maybe you know that script better and have an idea?

Oh I see. That's unfortunate. I can take a look at updating the script to handle annotations. We'll definitely want that for e.g. type annotations in the future.

dschuff · 2026-02-06T18:04:49Z

Regarding the name: do the semantics match any of the existing GCC attributes of const, pure, or reproducible? If so, maybe matching the name would be useful?

kripken · 2026-02-06T18:27:08Z

@dschuff Sadly I don't think they match those. gcc's pure etc are defined as variations of no observable effects on the state of the program other than to return a value, but the property here is conditional: these functions do have effects. They can only be considered effect-free if dropped.

Concretely, this is valid in gcc:

x = pure();
foo();
bar(x);

=>

foo();
bar(pure()); // pure function pushed past foo(), which it cannot interact with

But that is not valid if pure were instead dead if unused.

tlively · 2026-02-06T18:42:49Z

Maybe removable.if.unused to be more precise? It's not totally clear from the name whether dead.if.unused allows unconditionalizing calls, while removable.if.unused at least suggests that removing the call is the only thing allowed.

kripken · 2026-02-06T19:27:30Z

@tlively I think more than removability is possible, though. The full meaning is "has no effects if the value is not used". Perhaps effectless.if.dropped, but that feels a little verbose. pure.if.dropped might make sense but I worried it could be mixed up with gcc's pure. So I was thinking dead.if.dropped is clear enough, but yeah, maybe we can do better?

To clarify what I mean by more than removability being possible: imagine some code cannot be removed for technical, type-system or IR structure reasons. It might still be useful to know it has no effects. Not a great example, but:

(drop
  (block $block (result (ref $A))
    (br_if $block
      (local.get $value)
      (local.get $condition)
    )
    (call $dead.if.unused)
  )
)
(call $foo)

The dead.if.unused call here is dropped, but it can't be removed by itself - we need to do more optimization work (it is dropped through a block, and that block even has another branch). We do have optimizations that do it, of course, but imagine we didn't, so that chunk of code sticks around. We can at least move it past the (call $foo) at the end, if we know it has no effects, and maybe that is useful somewhere.

tlively · 2026-02-06T21:08:00Z

IIUC, we cannot move it past the call $foo in that example because that would unconditionalize its execution. This is different than a const or pure call, which would be able to be moved.

kripken · 2026-02-06T21:14:41Z

Ah, do you mean because the call might trap or throw? Fair enough. So amend my example to replace (call $foo) with (global.set $g (i32.const 42))

tlively · 2026-02-06T21:25:51Z

No, we couldn't move a call with this annotation past a global.set, either. The called function might trap if that global.set has been executed but not trap if it has not been executed. The assertion communicated by this annotation really is limited to "if the value is not observably used, then the call can be removed" without implying that any other special optimizations would be allowed.

kripken · 2026-02-07T00:05:17Z

Ok, after discussion offline I agree @tlively 's approach is better here. So I think renaming to removable.if.unused is a good idea (but will wait to do it on further discussion to avoid churn).

This also means that the optimization in this PR is the only thing the intrinsic allows: literally removing it from its current position, in Vacuum, and nothing else.

kripken added 30 commits January 20, 2026 16:12

go

5daee4c

work

7ce3151

work

477e77b

work

83583cb

fmt

073b39e

test

f129e51

work

075fd15

work

d540a96

builds

4d8b7a5

progress

e38e29c

finish

c78dc41

works

8ad0110

UNDO effects.h

d876266

yolo

31f6e5c

works

879dc79

rename

eadd3dc

rename

a49fe26

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

c2c1d9d

refactor

dce83d8

fix

93234e2

fmrt

eeba297

work

902a233

work

2e287a2

work

45650e1

work

017f8e5

work

4097eec

work

694e4f9

simpl

a815fb7

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

8214606

fmrt

6a88e93

kripken added 9 commits January 29, 2026 17:02

finish

d1eec83

work

a266a05

work

e474857

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

8c24e14

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

8e89cb4

hhow?

0b4d4f9

hhow?

7cac194

finish

0658143

fix

a2aea65

kripken requested a review from tlively February 5, 2026 16:44

kripken added 2 commits February 5, 2026 09:00

fix

a8857b5

fuzz

9b33ec1

kripken mentioned this pull request Feb 5, 2026

Pure calls / future of call.without.effects #7574

Open

tlively reviewed Feb 5, 2026

View reviewed changes

kripken added 6 commits February 5, 2026 14:30

test roundtripping of function-level annotation

ed1466f

simpler

dafbdbe

just use bool

708f8b2

fix

f3c73c6

unfuzz

1ad327c

default

6544c89

This was referenced Feb 6, 2026

clang annotation are not removed from binary in release builds emscripten-core/emscripten#26216

Open

Toolchain optimization hints? WebAssembly/tool-conventions#255

Open

	if (checkDeadIfUnused(getFunction(), call)) {
	if (getFunction()->getAnnotations(call).deadIfUnused) {

		// Check on the called function, if it exists (it may not if the IR is
		// still being built up).

	if (checkDeadIfUnused(target, nullptr)) {
	if (target->getFuncAnnotations().deadIfUnused) {

		@@ -0,0 +1,88 @@
		;; RUN: wasm-opt -all --vacuum %s -S -o - \| filecheck %s

Conversation

kripken commented Feb 5, 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!

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!

dschuff commented Feb 6, 2026

Uh oh!

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

Uh oh!

Uh oh!

tlively commented Feb 6, 2026

Uh oh!

kripken commented Feb 6, 2026

Uh oh!

tlively commented Feb 6, 2026

Uh oh!

kripken commented Feb 6, 2026

Uh oh!

tlively commented Feb 6, 2026

Uh oh!

kripken commented Feb 7, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

kripken commented Feb 6, 2026 •

edited

Loading