[wasm-split] Do multi-split at once

[aheejin]

This does multi-splitting of modules at once, rather than splitting them one by one by doing 2-way split n times. Previously when we did multi-splitting we split the 1st module as the "secondary" module assuming all other functions belonging to 2nd-nth modules as "primary" module. And then we repeat the same task for the 2nd module, assuming 3rd-nth module functions belong to the "primary" module. This unnecessarily repeated some tasks that could have been done once.

This reduces the running time on a reproducer provided by @biggs0125 before (to fix #7725) from 232s to 80s on my machine, reducing it by around 66%.

Some side-products of this PR are:

• Now we only create a single table to host placeholders (or ref.nulls in case of --no-placeholders) even when reference-types is enabled. Previously we created a table per secondary module, resulting in n tables.
• The names of trampoline functions have been changed in the tests, but semantically they are the same. (e.g. in test/lit/wasm-split/multi-split.wast) The reason for the change is, previously we split modules one by one, by the time we split the first module, it assumed functions belonging to other secondary modules were primary functions, but they later changed to trampolines as well. Now they are all named as trampolines, arguably enhancing readability.

---

Some detailed analysis run using the reproducer of #7725, a case where we split a module into 301 (1 primary + 300 secondary) modules:

• Before this PR:

Time: 232.9s

Task breakdown:

Task                                          Total Time (ms)      Percentage
---------------------------------------------------------------------------
shareImportableItems                               62139.5770          29.26%
classifyFunctions                                  42377.2849          19.95%
removeUnusedSecondaryElements                      33615.1043          15.83%
indirectReferencesToSecondaryFunctions             28047.9460          13.21%
indirectCallsToSecondaryFunctions                  25184.7922          11.86%
moveSecondaryFunctions                             14473.2277           6.82%
setupTablePatching                                  3126.4863           1.47%
initExportedPrimaryFuncs                            1674.4963           0.79%
exportImportCalledPrimaryFunctions                   936.1570           0.44%
thunkExportedSecondaryFunctions                      789.3036           0.37%
---------------------------------------------------------------------------
Overall Total                                     212364.3753         100.00%

• After this PR: (After addressing comments)

Time : 80.1s

Task breakdown:

Task                                          Total Time (ms)      Percentage
------------------------------------------------------------------------------
shareImportableItems                               35386.0000          48.46%
removeUnusedSecondaryElements                      27730.3000          37.98%
moveSecondaryFunctions                              4541.4800           6.22%
writeModule_secondary                               3176.7382           4.35%
writeModule_primary                                  997.8480           1.37%
exportImportCalledPrimaryFunctions                   649.7930           0.89%
indirectReferencesToSecondaryFunctions               269.4650           0.37%
indirectCallsToSecondaryFunctions                    136.9090           0.19%
classifyFunctions                                     88.8081           0.12%
setupTablePatching                                    40.6237           0.06%
thunkExportedSecondaryFunctions                        2.5536           0.00%
initExportedPrimaryFuncs                               0.5960           0.00%
------------------------------------------------------------------------------
Overall Total                                      73021.1146         100.00%

We can see time taken in classifyFunctions, indirectReferencesToSecondaryFunctions, and indirectCallsToSecondaryFunctions has reduced basically to nothing. This is because now we can scan all functions only once in those functions, where we used to scan the functions n times or similar.

Now shareImportableItems and moveSecondaryFunctions take up around 85% of the execution time. The reason shareImportableItems takes so long is the reproducer has 90k globals.

Analysis of shareImportableItems:
Sub-Task                                      Total Time (ms)      Percentage
-----------------------------------------------------------------------------
globals                                            41166.4904          98.35%
tables                                               535.5134           1.28%
tags                                                  10.3355           0.02%
memories                                               7.5937           0.02%
exports                                                1.5482           0.00%
-----------------------------------------------------------------------------
Total                                              41857.1000         100.00%

('exports' meaning processing existing exports)

We can probably improve this by selectively importing module items, as already noted by the existing TODO.

moveSecondaryFunctions basically just runs RemoveUnusedModuleElements on each module. But if we export only used items in shareImportableItems, running this pass may become unnecessary after all.

[aheejin]

"Hide whitespace" will make the diff easier to view.

[tlively]

Great work! This is a really nice improvement.

[aheejin]

After addressing comments, the execution time went down from 88s to 80s, and the improvement compared to main is around 66%. Probably thanks to less map lookups 😀

[tlively]

LGTM!