Avoid generating trampolines with --no-placeholders

Comienza en src/ir/module-splitting.cpp, en las dos ubicaciones enlazadas, y revisa cómo wasm-split gestiona --no-placeholders. Investiga el número de trampolines y si Dart u otra información sobre la carga de módulos puede establecer el orden de dependencias. El trabajo se considera terminado cuando exista un contrato de entrada o de loader definido que permita de forma segura las reducciones de trampolines previstas.

The wasm-split options --no-placeholders is used when the module loader can guarantee that secondary modules will be loaded before their functions are ever called. It currently has the effect of avoiding the creation of imported placeholder functions that are meant to lazily load secondary modules on demand, since these placeholders will never be run.

But we could also use the guarantee that the loader will have loaded modules before they are needed to avoid generating trampoline functions in many cases. We currently generate trampoline functions for two situations: 1) for secondary functions that are exported from the primary module (link), and 2) for secondary functions that are referenced from a different module (link).

For case 1), if modules are always loaded before they are needed, then exported secondary functions will never be called before their modules are loaded. We could therefore require the loader to append public secondary exports to the list of primary exports itself when it loads secondary modules rather than using a trampoline to provide the export from the primary module.

For case 2), we still need trampolines for secondary functions referenced from the primary module, since we cannot import those functions and we must have something to reference. But we might be able to avoid creating trampolines for secondary functions referenced from other secondary modules that we know will be loaded later. We would instead depend on the loader to append the exports from each loaded secondary module to the imports provided to the next, so later secondary modules could reference functions imported from earlier secondary modules directly.

The trouble here is knowing which secondary modules are "earlier" or "later" than others so we know which trampolines we can elide. The most explicit way to know this would be to have the user pass in a module dependence graph, perhaps as part of the manifest file. Alternatively we could depend on other information provided by the user. For example, we could provide a flag to let the user assert that modules only reference functions from earlier modules, which would then allow us to unconditionally skip inserting trampolines.

@biggs0125, is it the case that Dart modules will only reference functions provided by earlier Dart modules? If not, would it be feasible to pass a module dependence graph to wasm-split to help it improve its codegen?

@aheejin, does this optimization sound useful to you? It might be worth doing some preliminary investigation to see how many trampolines we are generating and how many are exported from the primary module and imported into secondary modules.