Intrinsic: binaryen.removable.if.unused

[kripken]

Based on discussion in

#7574 (comment)

the @binaryen.removable.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.

edit: updated, original name was dead.if.unused

[dschuff]

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]

@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]

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]

@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]

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]

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]

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]

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]

Updated to the final name @binaryen.removable.if.unused. That clarifies that removing it from the current position is the only thing the optimizer is allowed to do - not move it or otherwise. Also for now we'll prefix binaryen.* as it is specific to this project and its users - if other optimizers etc. want a more general name we can add one later in toolchain-conventions.