RemoveUnusedModuleElements: add option to remove nop exported functions

[BilelGho]

Fixes #6506.

Summary

• Adds pass argument remove-unused-module-elements-ignore-nop-exports to the RemoveUnusedModuleElements pass.
• When the argument is set, exported functions whose body is a single nop have their export entries removed before the normal DCE graph walk. If nothing else references the function, the function itself is also removed by the existing DCE logic.
• Functions that are nop but are called internally are kept (only the export is dropped).

Usage

wasm-opt input.wasm --remove-unused-module-elements \
  --pass-arg=remove-unused-module-elements-ignore-nop-exports \
  -o output.wasm

Motivation

Some runtimes (e.g. wasm-4, custom Rust runtimes) check whether a named export exists to decide behavior. A nop export misleads them into thinking a lifecycle hook is implemented, causing unexpected behavior. This option lets toolchains strip such stub exports produced by compilers that always emit lifecycle functions even when the user provides no implementation.

Test plan

• New lit test: test/lit/passes/remove-unused-module-elements-ignore-nop-exports.wast
  • Nop exported function → export and function removed
  • Non-nop exported function → kept
  • Nop function that is called internally → function kept, export removed

[kripken]

Some runtimes (e.g. wasm-4, custom Rust runtimes) check whether a named export exists to decide behavior. A nop export misleads them into thinking a lifecycle hook is implemented, causing unexpected behavior.

What is the exact behavior that is a problem in those runtimes?

(I'm not necessarily opposed to this functionality, but I'd like to understand the actual problem)

[BilelGho]

What is the exact behavior that is a problem in those runtimes?

(I'm not necessarily opposed to this functionality, but I'd like to understand the actual problem)

This is actually a bit of a misquote to this comment in this old issue by @orsinium
#6506 (comment)

I haven't checked myself tbh. Could be a good idea to check whether this is helpful first. I just found it as an open issue for new contributors. I wouldn't know if such runtimes wrote their workarounds or could still benefit of such option. Feel free to dismiss if it looks unnecessary.

[kripken]

Thanks for the info, I'd forgotten that old discussion.

I'd like to hear more from the runtimes that would benefit, if this is still important for them, before moving forward with a change.

[orsinium]

Thank you! I also forgot about the discussion, it's nice to see things moving forward :) I can't speak much for other runtimes beyond my old comment but for my runtime (Firefly Zero) that would be surely beneficial. For example, here if the render callback is not defined, we do some additional operations:

https://github.com/firefly-zero/firefly-runtime/blob/701039c318b48c5c22c7ecdd0022b1334c255ca8/src/runtime.rs#L265-L274