For any module which is not exported by the containing component, nothing can observe its imports and exports but that component.

So if an export of that module is not aliased in any instance of the module, that export can be removed from the module potentially enabling further module-level optimizations.

In the future, I'd like this project to expand to offer Component-aware optimization passes.

This issue will act to track proposed optimization passes and be updated in place.

• #2
• #3
• #4
• #5
• #6

It's possible combine together modules whose instances have export-alias-import relationships.

Benefits:

• Further module-level optimizations may now be possible.
• It may enable more dead item and dead module export elimination, reducing code size.

Considerations:

• If there are modules which are completely disconnected/independent from others, it may not make sense to merge them.
• If any modules are instantiated multiple times, this optimization could duplicate information depending on how it is configured.
• If multiple instances define memories, then the resulting module may require multi-memory even if none of them individually did.

Any item in a section which introduces an unused index can be removed.

e.g. aliases, types

Sometimes we can tell that a given Canonical Option doesn't affect the behavior of the component and can be removed.

The most obvious case is that neither a memory nor realloc option is needed if

• the total flat size of its parameters is less than MAX_FLAT_PARAMS,
• the total flat size of its return values is less than MAX_FLAT_RESULTS,
• and none of the param or result types transitively include allocating types (e.g. list<T>, string).

A more subtle case that may be too niche but could be considered is detecting that the post-return function has no side effects (likely due to other optimizations) and can be removed.

If there are multiple items that are redundant, the redundant copies can be removed.

e.g. two definitions of the same function type